Dom/Geniusia_v2
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
Dom
2026-03-05 00:20:25 +01:00
commit dcd4de9945
1954 changed files with 669380 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
.kiro/hooks/french-only-mode.kiro.hook Normal file
View File

@@ -0,0 +1,18 @@
{
"enabled": true,
"name": "Mode Français Uniquement. Instructions de codage",
"description": "Configure l'agent pour répondre uniquement en français à toutes les interactions et donne les instructions de codage",
"version": "1",
"when": {
"type": "fileEdited",
"patterns": [
"**/*"
]
},
"then": {
"type": "askAgent",
"prompt": "IMPORTANT: Tu dois répondre UNIQUEMENT en français. Toutes tes réponses, explications, commentaires de code, et communications doivent être en français. Ne parle jamais en anglais ou dans une autre langue. Analyse les changements de fichiers et réponds en français. Toujours vérifier que l'on ne dévis pas de l'objectifs principal. Ne jamais effectuer de test fictifs sans les vrais implementations, éléments, modéle etc ..."
},
"workspaceFolderName": "Geniusia_v2",
"shortName": "french-only-mode"
}

4
.kiro/settings/mcp.json Normal file
View File

@@ -0,0 +1,4 @@
{
"mcpServers": {
}
}

123
.kiro/specs/assisted-mode-suggestions/design.md Normal file
View File

@@ -0,0 +1,123 @@
# Design - Mode Assisté avec Suggestions
## Overview
Le Mode Assisté détecte quand l'utilisateur commence un workflow connu et propose de le compléter automatiquement. Le système compare les actions en cours avec les workflows sauvegardés et affiche une suggestion si la correspondance est suffisante.
## Architecture
```
User Actions → SessionManager → WorkflowMatcher → SuggestionManager → GUI
↓
Workflows (JSON)
```
**Flux** :
1. L'utilisateur effectue des actions
2. SessionManager crée une session en cours
3. WorkflowMatcher compare avec les workflows connus
4. Si match > 80%, SuggestionManager crée une suggestion
5. GUI affiche la suggestion avec timeout de 10s
6. Utilisateur accepte (Enter) ou rejette (Escape)
7. Si accepté, TaskReplayEngine exécute les étapes restantes
## Components
### 1. WorkflowMatcher (Nouveau)
**Responsabilité** : Comparer les actions courantes avec les workflows connus
**Méthodes** :
```python
def match_current_session(session, workflows) -> List[WorkflowMatch]:
"""Compare la session courante avec tous les workflows"""
def calculate_match_score(actions, workflow_steps) -> float:
"""Calcule le score de correspondance (0-1)"""
def find_best_match(matches) -> Optional[WorkflowMatch]:
"""Retourne le meilleur match si > 80%"""
```
**Algorithme de matching** :
- Comparer les N premières actions avec le début de chaque workflow
- Score = (actions_matching / total_actions) * position_similarity
- Position similarity : tolérance de 50px
### 2. SuggestionManager (Existant - À améliorer)
**Améliorations nécessaires** :
- Méthode `check_workflow_match()` : vérifie périodiquement les matchs
- Méthode `create_workflow_suggestion()` : crée une suggestion de workflow
- Gestion du timeout (10 secondes)
- Tracking des rejets pour ajuster la priorité
### 3. GUI Overlay (Existant - À améliorer)
**Améliorations** :
- Affichage des 3 prochaines étapes
- Boutons Enter/Escape bien visibles
- Barre de progression pendant l'exécution
- Notification de succès/échec
### 4. TaskReplayEngine (Existant)
**Utilisation** :
- Exécuter les étapes restantes du workflow
- Recherche visuelle pour chaque étape
- Feedback visuel pendant l'exécution
## Data Models
### WorkflowMatch
```python
@dataclass
class WorkflowMatch:
workflow_id: str
workflow_name: str
confidence: float
matched_steps: int
total_steps: int
remaining_steps: List[WorkflowStep]
```
### Suggestion (Existant - À étendre)
```python
{
"type": "workflow",
"workflow_id": str,
"workflow_name": str,
"confidence": float,
"current_step": int,
"remaining_steps": List[dict],
"created_at": datetime,
"timeout": 10.0
}
```
## Error Handling
- **Match échoue** : Continuer en mode manuel, ne pas suggérer
- **Exécution échoue** : Arrêter, notifier l'utilisateur, rollback optionnel
- **Timeout** : Dismisser la suggestion silencieusement
- **Rejet répété** : Réduire la priorité du workflow (confidence *= 0.9)
## Testing Strategy
### Unit Tests
- Test du matching avec différents workflows
- Test du calcul de score
- Test de la tolérance de position
- Test du timeout
### Integration Tests
- Test du flux complet : action → suggestion → exécution
- Test avec workflows réels de la calculatrice
- Test des rejets et acceptations
## Performance
- **Latence de détection** : < 500ms
- **Affichage suggestion** : < 1s après le match
- **Exécution par étape** : ~500ms (recherche visuelle + action)
- **Fréquence de vérification** : Toutes les 2 secondes en mode Assist

63
.kiro/specs/assisted-mode-suggestions/requirements.md Normal file
View File

@@ -0,0 +1,63 @@
# Requirements - Mode Assisté avec Suggestions
## Introduction
Ce document spécifie les exigences pour le Mode Assisté de GeniusIA v2. Le système doit détecter quand l'utilisateur commence un workflow connu et proposer de le compléter automatiquement.
## Glossary
- **Mode Assisté** : Mode où le système suggère des actions mais attend validation
- **Suggestion** : Proposition d'action basée sur un workflow détecté
- **Workflow Match** : Correspondance entre les actions courantes et un workflow connu
- **Confidence Score** : Score de confiance (0-1) pour une suggestion
- **Timeout** : Durée avant qu'une suggestion expire
## Requirements
### Requirement 1
**User Story:** As a user, I want the system to detect when I start a known workflow, so that it can suggest completing it automatically.
#### Acceptance Criteria
1. WHEN the user performs actions in Assist mode THEN the system SHALL compare them with known workflows
2. WHEN the current actions match the beginning of a workflow THEN the system SHALL calculate a confidence score
3. WHEN the confidence score exceeds 80% THEN the system SHALL create a suggestion
4. WHEN a suggestion is created THEN the system SHALL display it to the user within 1 second
5. WHEN multiple workflows match THEN the system SHALL suggest the one with highest confidence
### Requirement 2
**User Story:** As a user, I want to accept or reject suggestions easily, so that I can control the automation.
#### Acceptance Criteria
1. WHEN a suggestion is displayed THEN the system SHALL show the workflow name and remaining steps
2. WHEN the user presses Enter THEN the system SHALL accept the suggestion and execute remaining steps
3. WHEN the user presses Escape THEN the system SHALL reject the suggestion and continue manual mode
4. WHEN the user ignores a suggestion for 10 seconds THEN the system SHALL automatically dismiss it
5. WHEN a suggestion is accepted THEN the system SHALL execute steps with visual feedback
### Requirement 3
**User Story:** As a user, I want suggestions to be accurate, so that I don't get interrupted with irrelevant proposals.
#### Acceptance Criteria
1. WHEN calculating workflow match THEN the system SHALL compare action types and positions
2. WHEN comparing positions THEN the system SHALL allow 50px tolerance
3. WHEN a workflow has been rejected 3 times THEN the system SHALL reduce its suggestion priority
4. WHEN a workflow is successfully executed THEN the system SHALL increase its confidence score
5. WHEN the user is in a different window THEN the system SHALL only suggest workflows for that window
### Requirement 4
**User Story:** As a user, I want to see what the system will do, so that I can trust the automation.
#### Acceptance Criteria
1. WHEN displaying a suggestion THEN the system SHALL show the next 3 steps
2. WHEN displaying steps THEN the system SHALL include action type and target description
3. WHEN a step is executed THEN the system SHALL highlight it visually
4. WHEN execution fails THEN the system SHALL stop and notify the user
5. WHEN all steps complete THEN the system SHALL show a success notification

60
.kiro/specs/assisted-mode-suggestions/tasks.md Normal file
View File

@@ -0,0 +1,60 @@
# Implementation Plan - Mode Assisté avec Suggestions
- [x] 1. Créer WorkflowMatcher ✅ FAIT
- [x] Créer `geniusia2/core/workflow_matcher.py`
- [x] Implémenter `match_current_session()`
- [x] Implémenter `calculate_match_score()` avec tolérance de position
- [x] Implémenter `find_best_match()`
- [x] Tests basiques inclus dans le fichier
- _Requirements: 1.1, 1.2, 1.3, 3.1, 3.2_
- [x] 2. Améliorer SuggestionManager ✅ FAIT
- [x] Ajouter `check_workflow_match()` pour vérification périodique
- [x] Ajouter `create_workflow_suggestion()` avec détails des étapes
- [x] Implémenter tracking des rejets (compteur par workflow)
- [x] Ajuster la priorité après 3 rejets
- [x] Tracking des acceptations pour améliorer la priorité
- _Requirements: 1.4, 1.5, 3.3, 3.5_
- [x] 3. Intégrer dans Orchestrator ✅ FAIT
- [x] Ajouter `_check_workflow_match()` pour vérifier les correspondances
- [x] Appeler dans `check_for_suggestions()` (déjà appelé périodiquement)
- [x] Passer la session courante et les workflows chargés
- [x] Créer suggestion de workflow si match trouvé
- [x] Priorité aux workflows sur les suggestions classiques
- _Requirements: 1.1, 1.4_
- [ ] 4. Améliorer GUI Overlay ⚠️ PARTIEL
- [ ] Afficher les 3 prochaines étapes dans la suggestion
- [ ] Ajouter barre de progression pendant l'exécution
- [x] Améliorer les boutons Enter/Escape (déjà implémenté)
- [ ] Ajouter notification de succès/échec
- _Requirements: 2.1, 2.2, 2.3, 4.1, 4.2, 4.5_
- _Note: GUI de base fonctionne, améliorations UI/UX à faire_
- [ ] 5. Améliorer TaskReplayEngine ⚠️ PARTIEL
- [ ] Ajouter feedback visuel par étape
- [ ] Implémenter arrêt sur échec avec notification
- [ ] Ajouter highlighting de l'étape en cours
- _Requirements: 2.5, 4.3, 4.4_
- _Note: Replay fonctionne, feedback visuel à améliorer_
- [x] 6. Implémenter timeout et dismiss ✅ FAIT
- [x] Timer de 10s dans SuggestionManager (déjà implémenté)
- [x] Auto-dismiss après timeout (méthode `check_timeout()`)
- [x] Callback `on_suggestion_timeout`
- _Requirements: 2.4_
- [ ] 7. Tester avec workflows Calculatrice
- Lancer en mode Assist
- Commencer un workflow connu
- Vérifier que la suggestion apparaît
- Accepter et vérifier l'exécution
- Rejeter et vérifier le dismiss
- _Requirements: All_
- [ ] 8. Ajuster les seuils
- Tester avec différents seuils de confiance
- Ajuster la tolérance de position si nécessaire
- Optimiser la fréquence de vérification
- _Requirements: 1.3, 3.2_

508
.kiro/specs/embedding-improvement/design.md Normal file
View File

@@ -0,0 +1,508 @@
# Design - Amélioration du Système d'Embeddings et Fine-tuning
## Overview
Le système d'embeddings actuel utilise CLIP avec FAISS mais souffre de problèmes de dimensions et de performance. Cette amélioration corrige FAISS, crée une abstraction pour supporter plusieurs modèles (CLIP baseline, Pix2Struct pour UI), et ajoute un fine-tuning léger incrémental qui s'exécute toutes les 10 nouvelles interactions pour améliorer la précision.
## Architecture
```
┌─────────────────────────────────────────────────────────────┐
│ Embedding System │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ EmbedderBase │◄─────│ CLIPEmbedder │ │
│ │ (Abstract) │ └──────────────┘ │
│ └──────┬───────┘ │
│ │ │
│ │ ┌────────────────────┐ │
│ └──────────────│ Pix2StructEmbedder │ │
│ └────────────────────┘ │
│ │
│ ┌────────────────────────────────────────────────────┐ │
│ │ EmbeddingManager │ │
│ │ - Model selection & fallback │ │
│ │ - Caching (LRU 1000 entries) │ │
│ │ - GPU/CPU management │ │
│ └────────────────────────────────────────────────────┘ │
│ │
│ ┌────────────────────────────────────────────────────┐ │
│ │ FAISSIndex │ │
│ │ - Fixed dimension handling │ │
│ │ - Persistence (index + metadata) │ │
│ │ - Auto-rebuild on dimension change │ │
│ └────────────────────────────────────────────────────┘ │
│ │
│ ┌────────────────────────────────────────────────────┐ │
│ │ LightweightFineTuner │ │
│ │ - Collects positive/negative examples │ │
│ │ - Triggers every 10 examples │ │
│ │ - Runs in background thread │ │
│ │ - Updates last layer only │ │
│ └────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
│ │ │
▼ ▼ ▼
WorkflowMatcher VisionAnalysis SessionManager
```
## Components and Interfaces
### 1. EmbedderBase (Abstract Interface)
**Responsabilité**: Interface commune pour tous les modèles d'embedding
```python
from abc import ABC, abstractmethod
from PIL import Image
import numpy as np
class EmbedderBase(ABC):
@abstractmethod
def embed(self, image: Image.Image) -> np.ndarray:
"""Generate embedding for an image
Returns:
np.ndarray: Normalized embedding vector
"""
pass
@abstractmethod
def get_dimension(self) -> int:
"""Get embedding dimension"""
pass
@abstractmethod
def get_model_name(self) -> str:
"""Get model identifier"""
pass
@abstractmethod
def supports_batch(self) -> bool:
"""Check if model supports batch processing"""
pass
def embed_batch(self, images: List[Image.Image]) -> np.ndarray:
"""Generate embeddings for multiple images (optional optimization)"""
return np.array([self.embed(img) for img in images])
```
### 2. CLIPEmbedder (Concrete Implementation)
**Responsabilité**: Wrapper pour CLIP avec l'interface commune
```python
class CLIPEmbedder(EmbedderBase):
def __init__(self, device='cuda' if torch.cuda.is_available() else 'cpu'):
self.device = device
self.model, self.preprocess = clip.load("ViT-B/32", device=device)
self.model.eval()
def embed(self, image: Image.Image) -> np.ndarray:
with torch.no_grad():
image_tensor = self.preprocess(image).unsqueeze(0).to(self.device)
embedding = self.model.encode_image(image_tensor)
embedding = embedding / embedding.norm(dim=-1, keepdim=True)
return embedding.cpu().numpy().flatten()
def get_dimension(self) -> int:
return 512 # CLIP ViT-B/32 dimension
def get_model_name(self) -> str:
return "clip-vit-b32"
def supports_batch(self) -> bool:
return True
```
### 3. Pix2StructEmbedder (Concrete Implementation)
**Responsabilité**: Wrapper pour Pix2Struct spécialisé UI
```python
from transformers import Pix2StructProcessor, Pix2StructForConditionalGeneration
class Pix2StructEmbedder(EmbedderBase):
def __init__(self, device='cuda' if torch.cuda.is_available() else 'cpu'):
self.device = device
self.processor = Pix2StructProcessor.from_pretrained(
"google/pix2struct-base"
)
self.model = Pix2StructForConditionalGeneration.from_pretrained(
"google/pix2struct-base"
).to(device)
self.model.eval()
def embed(self, image: Image.Image) -> np.ndarray:
with torch.no_grad():
inputs = self.processor(images=image, return_tensors="pt").to(self.device)
# Extract encoder hidden states as embeddings
encoder_outputs = self.model.encoder(**inputs)
embedding = encoder_outputs.last_hidden_state.mean(dim=1)
embedding = embedding / embedding.norm(dim=-1, keepdim=True)
return embedding.cpu().numpy().flatten()
def get_dimension(self) -> int:
return 768 # Pix2Struct base dimension
def get_model_name(self) -> str:
return "pix2struct-base"
def supports_batch(self) -> bool:
return True
```
### 4. EmbeddingManager
**Responsabilité**: Gestion des modèles, cache, et sélection
```python
from functools import lru_cache
from typing import Optional
class EmbeddingManager:
def __init__(self, model_name: str = "clip", fallback: bool = True):
self.model_name = model_name
self.fallback_enabled = fallback
self.embedder = self._load_embedder()
self._cache = {} # Manual LRU cache
self._cache_order = []
self.max_cache_size = 1000
def _load_embedder(self) -> EmbedderBase:
"""Load embedder with fallback"""
try:
if self.model_name == "pix2struct":
return Pix2StructEmbedder()
elif self.model_name == "clip":
return CLIPEmbedder()
else:
raise ValueError(f"Unknown model: {self.model_name}")
except Exception as e:
if self.fallback_enabled:
logger.warning(f"Failed to load {self.model_name}, falling back to CLIP: {e}")
return CLIPEmbedder()
raise
def embed(self, image: Image.Image) -> np.ndarray:
"""Generate embedding with caching"""
# Create cache key from image hash
img_hash = hashlib.md5(image.tobytes()).hexdigest()
if img_hash in self._cache:
return self._cache[img_hash]
# Generate embedding
embedding = self.embedder.embed(image)
# Update cache
self._cache[img_hash] = embedding
self._cache_order.append(img_hash)
# Evict if needed
if len(self._cache) > self.max_cache_size:
oldest = self._cache_order.pop(0)
del self._cache[oldest]
return embedding
def get_dimension(self) -> int:
return self.embedder.get_dimension()
def get_model_name(self) -> str:
return self.embedder.get_model_name()
```
### 5. FAISSIndex (Fixed)
**Responsabilité**: Gestion de l'index FAISS avec correction des bugs
```python
import faiss
import pickle
class FAISSIndex:
def __init__(self, dimension: int):
self.dimension = dimension
self.index = faiss.IndexFlatL2(dimension)
self.metadata = [] # Store workflow IDs and step info
def add(self, embeddings: np.ndarray, metadata: List[dict]):
"""Add embeddings to index
Args:
embeddings: Shape (N, dimension)
metadata: List of N metadata dicts
"""
if embeddings.shape[1] != self.dimension:
raise ValueError(
f"Embedding dimension {embeddings.shape[1]} doesn't match "
f"index dimension {self.dimension}"
)
self.index.add(embeddings.astype('float32'))
self.metadata.extend(metadata)
def search(self, query: np.ndarray, k: int = 5) -> List[dict]:
"""Search for similar embeddings
Args:
query: Shape (1, dimension) or (dimension,)
k: Number of results
Returns:
List of dicts with 'distance', 'metadata'
"""
if query.ndim == 1:
query = query.reshape(1, -1)
if query.shape[1] != self.dimension:
raise ValueError(
f"Query dimension {query.shape[1]} doesn't match "
f"index dimension {self.dimension}"
)
distances, indices = self.index.search(query.astype('float32'), k)
results = []
for dist, idx in zip(distances[0], indices[0]):
if idx < len(self.metadata):
results.append({
'distance': float(dist),
'similarity': 1.0 / (1.0 + dist), # Convert to similarity
'metadata': self.metadata[idx]
})
return results
def save(self, path: str):
"""Save index and metadata"""
faiss.write_index(self.index, f"{path}.index")
with open(f"{path}.metadata", 'wb') as f:
pickle.dump({
'dimension': self.dimension,
'metadata': self.metadata
}, f)
def load(self, path: str):
"""Load index and metadata"""
self.index = faiss.read_index(f"{path}.index")
with open(f"{path}.metadata", 'rb') as f:
data = pickle.load(f)
self.dimension = data['dimension']
self.metadata = data['metadata']
def rebuild_if_needed(self, new_dimension: int):
"""Rebuild index if dimension changed"""
if new_dimension != self.dimension:
logger.info(f"Rebuilding FAISS index: {self.dimension} -> {new_dimension}")
old_metadata = self.metadata
self.dimension = new_dimension
self.index = faiss.IndexFlatL2(new_dimension)
self.metadata = []
# Note: Old embeddings are lost, need to regenerate
return True
return False
```
### 6. LightweightFineTuner
**Responsabilité**: Fine-tuning incrémental en arrière-plan
```python
import threading
from collections import deque
class LightweightFineTuner:
def __init__(self, embedder: EmbedderBase, trigger_threshold: int = 10):
self.embedder = embedder
self.trigger_threshold = trigger_threshold
self.positive_examples = deque(maxlen=1000)
self.negative_examples = deque(maxlen=1000)
self.is_training = False
self.training_thread = None
def add_positive_example(self, image: Image.Image, workflow_id: str):
"""Add successful workflow execution example"""
self.positive_examples.append({
'image': image,
'workflow_id': workflow_id,
'timestamp': time.time()
})
self._check_trigger()
def add_negative_example(self, image: Image.Image, workflow_id: str):
"""Add rejected workflow suggestion example"""
self.negative_examples.append({
'image': image,
'workflow_id': workflow_id,
'timestamp': time.time()
})
self._check_trigger()
def _check_trigger(self):
"""Check if we should trigger fine-tuning"""
total_new = len(self.positive_examples) + len(self.negative_examples)
if total_new >= self.trigger_threshold and not self.is_training:
logger.info(f"Triggering fine-tuning with {total_new} new examples")
self._start_training()
def _start_training(self):
"""Start training in background thread"""
self.training_thread = threading.Thread(target=self._train)
self.training_thread.daemon = True
self.training_thread.start()
def _train(self):
"""Fine-tune the last layer of the model"""
self.is_training = True
try:
# Only for models that support fine-tuning (not CLIP base)
if not hasattr(self.embedder, 'fine_tune'):
logger.info("Model doesn't support fine-tuning, skipping")
return
# Prepare training data
positive_images = [ex['image'] for ex in self.positive_examples]
negative_images = [ex['image'] for ex in self.negative_examples]
# Fine-tune (implementation depends on model)
metrics = self.embedder.fine_tune(
positive_images=positive_images,
negative_images=negative_images,
epochs=1,
learning_rate=1e-4
)
logger.info(f"Fine-tuning complete: {metrics}")
# Clear examples after training
self.positive_examples.clear()
self.negative_examples.clear()
except Exception as e:
logger.error(f"Fine-tuning failed: {e}")
finally:
self.is_training = False
def save_checkpoint(self, path: str):
"""Save training examples for recovery"""
with open(path, 'wb') as f:
pickle.dump({
'positive': list(self.positive_examples),
'negative': list(self.negative_examples)
}, f)
def load_checkpoint(self, path: str):
"""Load training examples"""
with open(path, 'rb') as f:
data = pickle.load(f)
self.positive_examples.extend(data['positive'])
self.negative_examples.extend(data['negative'])
```
## Data Models
### EmbeddingMetadata
```python
@dataclass
class EmbeddingMetadata:
workflow_id: str
step_index: int
action_type: str
timestamp: float
model_name: str
model_version: str
```
### FineTuningMetrics
```python
@dataclass
class FineTuningMetrics:
loss: float
accuracy: float
positive_examples: int
negative_examples: int
duration_seconds: float
timestamp: float
```
## 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: Embedding Dimension Consistency
*For any* embedder instance, all generated embeddings SHALL have the same dimension as reported by `get_dimension()`
**Validates: Requirements 1.1, 2.2, 3.3**
### Property 2: FAISS Index Persistence Round-trip
*For any* FAISS index with embeddings, saving then loading SHALL restore the exact same search results
**Validates: Requirements 1.3, 1.4**
### Property 3: Embedder Interface Compatibility
*For any* embedder implementation (CLIP or Pix2Struct), calling `embed()` with a valid PIL image SHALL return a normalized numpy array
**Validates: Requirements 2.1, 2.2, 2.5**
### Property 4: Cache Hit Consistency
*For any* image, generating embeddings twice SHALL return identical results (via caching)
**Validates: Requirements 6.1**
### Property 5: Fallback Reliability
*For any* model loading failure, if fallback is enabled, the system SHALL successfully load CLIP without raising exceptions
**Validates: Requirements 2.4, 3.5**
### Property 6: Fine-tuning Non-blocking
*For any* fine-tuning operation, the main thread SHALL continue generating embeddings without blocking
**Validates: Requirements 5.1, 5.2**
### Property 7: Example Collection Bounds
*For any* sequence of positive/negative examples, the collection SHALL never exceed 1000 examples (deque maxlen)
**Validates: Requirements 4.1, 4.2**
## Error Handling
- **Model loading fails**: Fallback to CLIP if enabled, otherwise raise clear error
- **Dimension mismatch**: Rebuild FAISS index automatically, log warning
- **GPU unavailable**: Fall back to CPU seamlessly
- **Fine-tuning fails**: Log error, keep current model, don't crash
- **Cache overflow**: Evict LRU entries automatically
- **Corrupted index file**: Rebuild from scratch, log error
## Testing Strategy
### Unit Tests
- Test each embedder implementation independently
- Test FAISS index add/search/save/load operations
- Test cache eviction logic
- Test dimension mismatch handling
- Test fallback mechanism
### Property-Based Tests
- Property 1: Dimension consistency across random images
- Property 2: FAISS round-trip with random embeddings
- Property 3: Interface compatibility with random PIL images
- Property 4: Cache consistency with duplicate images
- Property 5: Fallback with simulated failures
- Property 6: Fine-tuning non-blocking with concurrent operations
- Property 7: Example collection bounds with random additions
### Integration Tests
- Test full workflow: image → embedding → FAISS → search
- Test model switching (CLIP ↔ Pix2Struct)
- Test fine-tuning trigger and execution
- Test system behavior under GPU/CPU switching
## Performance
- **Embedding generation**: < 200ms per image (GPU), < 500ms (CPU)
- **FAISS search**: < 10ms for k=5 in index of 10,000 embeddings
- **Cache hit**: < 1ms
- **Fine-tuning**: < 2 minutes for 100 examples
- **Model loading**: < 5 seconds (CLIP), < 10 seconds (Pix2Struct)
- **Memory usage**: ~2GB (CLIP), ~4GB (Pix2Struct), ~500MB (FAISS index for 10k embeddings)

102
.kiro/specs/embedding-improvement/requirements.md Normal file
View File

@@ -0,0 +1,102 @@
# Requirements - Amélioration du Système d'Embeddings et Fine-tuning
## Introduction
Ce document spécifie les exigences pour améliorer le système d'embeddings visuels utilisé pour le matching de workflows. Le système doit corriger les problèmes FAISS actuels, créer une abstraction pour supporter plusieurs modèles (CLIP, Pix2Struct), et implémenter un fine-tuning léger incrémental pour améliorer la précision au fil du temps.
## Glossary
- **Embedding**: Représentation vectorielle d'une image capturée d'écran
- **FAISS**: Bibliothèque Facebook AI pour la recherche de similarité vectorielle
- **CLIP**: Modèle vision-language d'OpenAI pour les embeddings génériques
- **Pix2Struct**: Modèle Google spécialisé pour la compréhension d'interfaces utilisateur
- **Fine-tuning Léger**: Ajustement incrémental de la dernière couche du modèle
- **Embedder**: Interface abstraite pour générer des embeddings d'images
- **Workflow Match**: Correspondance entre une situation actuelle et un workflow connu
## Requirements
### Requirement 1
**User Story:** As a developer, I want the FAISS embedding system to work correctly, so that workflow matching can function reliably.
#### Acceptance Criteria
1. WHEN the system generates embeddings THEN the FAISS index SHALL store them without dimension errors
2. WHEN the system searches for similar embeddings THEN FAISS SHALL return results with valid similarity scores
3. WHEN embeddings are saved to disk THEN the system SHALL persist both the index and metadata correctly
4. WHEN embeddings are loaded from disk THEN the system SHALL restore the exact same index state
5. WHEN the embedding dimension changes THEN the system SHALL rebuild the index automatically
### Requirement 2
**User Story:** As a developer, I want an abstraction layer for embedding models, so that I can easily switch between CLIP and Pix2Struct.
#### Acceptance Criteria
1. WHEN creating an embedder THEN the system SHALL provide a common interface for all models
2. WHEN generating embeddings THEN the interface SHALL accept PIL images and return numpy arrays
3. WHEN switching models THEN the system SHALL maintain backward compatibility with existing workflows
4. WHEN a model fails to load THEN the system SHALL fallback to CLIP automatically
5. WHEN using different models THEN the system SHALL normalize embeddings to comparable scales
### Requirement 3
**User Story:** As a user, I want Pix2Struct to be available as an embedding model, so that UI matching accuracy improves over CLIP.
#### Acceptance Criteria
1. WHEN Pix2Struct is selected THEN the system SHALL load the model on first use
2. WHEN generating embeddings with Pix2Struct THEN the system SHALL use GPU if available
3. WHEN Pix2Struct generates embeddings THEN they SHALL have consistent dimensions
4. WHEN comparing Pix2Struct and CLIP THEN Pix2Struct SHALL show better UI element recognition
5. WHEN Pix2Struct is unavailable THEN the system SHALL fallback to CLIP without errors
### Requirement 4
**User Story:** As a user, I want the system to learn from my usage patterns, so that workflow matching improves over time.
#### Acceptance Criteria
1. WHEN a workflow is successfully executed THEN the system SHALL collect the screen embeddings as positive examples
2. WHEN a workflow suggestion is rejected THEN the system SHALL collect the screen embeddings as negative examples
3. WHEN 10 new examples are collected THEN the system SHALL trigger a lightweight fine-tuning update
4. WHEN fine-tuning runs THEN the system SHALL complete within 2 minutes
5. WHEN fine-tuning completes THEN the system SHALL update the model weights without restarting
### Requirement 5
**User Story:** As a user, I want fine-tuning to happen in the background, so that it doesn't interrupt my work.
#### Acceptance Criteria
1. WHEN fine-tuning is triggered THEN the system SHALL run it in a separate thread
2. WHEN fine-tuning is running THEN the system SHALL continue using the current model
3. WHEN fine-tuning completes THEN the system SHALL swap to the new model atomically
4. WHEN fine-tuning fails THEN the system SHALL log the error and keep the current model
5. WHEN the system shuts down during fine-tuning THEN the system SHALL save partial progress
### Requirement 6
**User Story:** As a developer, I want the embedding system to be efficient, so that it doesn't slow down the application.
#### Acceptance Criteria
1. WHEN generating embeddings THEN the system SHALL cache results for identical images
2. WHEN the cache exceeds 1000 entries THEN the system SHALL evict least recently used entries
3. WHEN using GPU THEN the system SHALL batch multiple embedding requests
4. WHEN GPU is unavailable THEN the system SHALL use CPU without errors
5. WHEN measuring performance THEN embedding generation SHALL take less than 200ms per image
### Requirement 7
**User Story:** As a user, I want to see which embedding model is being used, so that I can understand system behavior.
#### Acceptance Criteria
1. WHEN the system starts THEN the system SHALL log which embedding model is loaded
2. WHEN fine-tuning completes THEN the system SHALL log the improvement metrics
3. WHEN switching models THEN the system SHALL notify the user via logs
4. WHEN embeddings are generated THEN the system SHALL include model metadata
5. WHEN debugging THEN the system SHALL provide embedding visualization tools

306
.kiro/specs/embedding-improvement/tasks.md Normal file
View File

@@ -0,0 +1,306 @@
# Implementation Plan - Amélioration du Système d'Embeddings et Fine-tuning
## Phase 1: Fix FAISS et Abstraction de Base
- [x] 1. Créer l'abstraction EmbedderBase
- Créer `geniusia2/core/embedders/__init__.py`
- Créer `geniusia2/core/embedders/base.py` avec classe abstraite `EmbedderBase`
- Définir méthodes: `embed()`, `get_dimension()`, `get_model_name()`, `supports_batch()`, `embed_batch()`
- Ajouter docstrings complètes
- _Requirements: 2.1, 2.2_
- [x] 2. Implémenter CLIPEmbedder
- Créer `geniusia2/core/embedders/clip_embedder.py`
- Wrapper autour du code CLIP existant dans `vision_analysis.py`
- Implémenter toutes les méthodes de `EmbedderBase`
- Gérer GPU/CPU automatiquement
- Normaliser les embeddings (L2 norm)
- _Requirements: 2.1, 2.2, 2.5, 6.4_
- [x] 3. Créer FAISSIndex corrigé
- Créer `geniusia2/core/embedders/faiss_index.py`
- Implémenter `add()` avec validation de dimension
- Implémenter `search()` avec conversion distance→similarity
- Implémenter `save()` et `load()` avec metadata
- Implémenter `rebuild_if_needed()` pour changement de dimension
- Gérer les cas d'erreur (dimension mismatch, fichier corrompu)
- _Requirements: 1.1, 1.2, 1.3, 1.4, 1.5_
- [ ]* 3.1 Écrire tests unitaires pour FAISSIndex
- Test add/search avec différentes dimensions
- Test save/load round-trip
- Test rebuild sur changement de dimension
- Test gestion d'erreurs
- _Requirements: 1.1, 1.2, 1.3, 1.4, 1.5_
- [ ]* 3.2 Écrire test de propriété pour FAISS round-trip
- **Property 2: FAISS Index Persistence Round-trip**
- **Validates: Requirements 1.3, 1.4**
- Générer embeddings aléatoires, sauvegarder, charger, vérifier résultats identiques
- [x] 4. Créer EmbeddingManager
- Créer `geniusia2/core/embedders/embedding_manager.py`
- Implémenter sélection de modèle avec fallback
- Implémenter cache LRU manuel (1000 entrées)
- Utiliser hash MD5 de l'image comme clé de cache
- Logger le modèle chargé au démarrage
- _Requirements: 2.3, 2.4, 6.1, 6.2, 7.1, 7.3_
- [ ]* 4.1 Écrire tests pour EmbeddingManager
- Test sélection de modèle
- Test fallback sur erreur
- Test cache hit/miss
- Test éviction LRU
- _Requirements: 2.4, 6.1, 6.2_
- [ ]* 4.2 Écrire test de propriété pour cache consistency
- **Property 4: Cache Hit Consistency**
- **Validates: Requirements 6.1**
- Générer images aléatoires, embedder 2x, vérifier résultats identiques
- [x] 5. Intégrer dans vision_analysis.py
- Remplacer le code CLIP direct par `EmbeddingManager`
- Ajouter paramètre de config pour choisir le modèle (clip/pix2struct)
- Migrer les embeddings existants si nécessaire
- Maintenir backward compatibility
- _Requirements: 2.3, 2.4_
- [x] 6. Intégrer dans workflow_matcher.py
- Utiliser `EmbeddingManager` au lieu de CLIP direct
- Utiliser `FAISSIndex` pour les recherches de similarité
- Gérer le cas où l'index n'existe pas encore
- _Requirements: 1.1, 1.2_
- [x] 7. Checkpoint - Tester le système de base
- Lancer l'application en mode Assist
- Vérifier que les embeddings sont générés correctement
- Vérifier que FAISS fonctionne sans erreurs de dimension
- Vérifier que le cache fonctionne
- Tester save/load de l'index FAISS
- Ensure all tests pass, ask the user if questions arise.
## Phase 2: Ajouter Pix2Struct
- [x] 8. Installer dépendances Pix2Struct
- Ajouter `transformers>=4.35.0` à requirements
- Ajouter `sentencepiece` à requirements
- Créer script d'installation `install_pix2struct.sh`
- Tester l'installation sur la machine cible
- _Requirements: 3.1_
- [x] 9. Implémenter Pix2StructEmbedder
- Créer `geniusia2/core/embedders/pix2struct_embedder.py`
- Charger le modèle `google/pix2struct-base`
- Extraire les hidden states de l'encoder comme embeddings
- Normaliser les embeddings (L2 norm)
- Gérer GPU/CPU automatiquement
- Implémenter toutes les méthodes de `EmbedderBase`
- _Requirements: 3.1, 3.2, 3.3, 3.5_
- [ ]* 9.1 Écrire tests pour Pix2StructEmbedder
- Test chargement du modèle
- Test génération d'embeddings
- Test dimension consistency
- Test GPU/CPU switching
- _Requirements: 3.1, 3.2, 3.3_
- [ ]* 9.2 Écrire test de propriété pour interface compatibility
- **Property 3: Embedder Interface Compatibility**
- **Validates: Requirements 2.1, 2.2, 2.5**
- Tester CLIP et Pix2Struct avec images PIL aléatoires, vérifier format de sortie
- [x] 10. Tester Pix2Struct vs CLIP
- Créer script de benchmark `test_pix2struct_vs_clip.py`
- Comparer la qualité des embeddings sur des screenshots UI
- Mesurer les performances (temps, mémoire)
- Documenter les résultats
- _Requirements: 3.4, 6.5_
- [x] 11. Ajouter configuration pour sélection de modèle
- Ajouter paramètre `embedding_model` dans config
- Valeurs possibles: "clip", "pix2struct"
- Défaut: "clip" (pour compatibilité)
- Documenter dans README
- _Requirements: 2.3, 7.1_
- [x] 12. Checkpoint - Tester Pix2Struct
- Lancer avec `embedding_model=pix2struct`
- Vérifier que le modèle charge correctement
- Comparer la précision du matching avec CLIP
- Vérifier le fallback si Pix2Struct échoue
- Ensure all tests pass, ask the user if questions arise.
## Phase 3: Fine-tuning Léger
- [x] 13. Créer LightweightFineTuner
- Créer `geniusia2/core/embedders/fine_tuner.py`
- Implémenter collection d'exemples positifs/négatifs (deque maxlen=1000)
- Implémenter trigger automatique tous les 10 exemples
- Implémenter exécution en thread séparé
- Implémenter sauvegarde/chargement de checkpoint
- _Requirements: 4.1, 4.2, 4.3, 5.1, 5.5_
- [ ]* 13.1 Écrire tests pour LightweightFineTuner
- Test collection d'exemples
- Test trigger threshold
- Test thread séparé (non-blocking)
- Test checkpoint save/load
- _Requirements: 4.1, 4.2, 4.3, 5.1_
- [ ]* 13.2 Écrire test de propriété pour example collection bounds
- **Property 7: Example Collection Bounds**
- **Validates: Requirements 4.1, 4.2**
- Ajouter N exemples aléatoires (N > 1000), vérifier que len <= 1000
- [ ]* 13.3 Écrire test de propriété pour fine-tuning non-blocking
- **Property 6: Fine-tuning Non-blocking**
- **Validates: Requirements 5.1, 5.2**
- Lancer fine-tuning, vérifier que embed() continue de fonctionner
- [x] 14. Implémenter fine-tuning pour CLIPEmbedder
- Ajouter méthode `fine_tune()` à `CLIPEmbedder`
- Utiliser contrastive loss (positifs vs négatifs)
- Fine-tuner uniquement la dernière couche de projection
- Utiliser learning rate faible (1e-4)
- Limiter à 1 epoch pour rapidité
- Retourner métriques (loss, accuracy)
- _Requirements: 4.4, 5.2, 5.3, 7.2_
- [x] 15. Implémenter fine-tuning pour Pix2StructEmbedder
- Ajouter méthode `fine_tune()` à `Pix2StructEmbedder`
- Utiliser contrastive loss (positifs vs négatifs)
- Fine-tuner uniquement la dernière couche de l'encoder
- Utiliser learning rate faible (1e-4)
- Limiter à 1 epoch pour rapidité
- Retourner métriques (loss, accuracy)
- _Requirements: 4.4, 5.2, 5.3, 7.2_
- [x] 16. Intégrer fine-tuning dans Orchestrator
- Ajouter `LightweightFineTuner` à l'orchestrator
- Appeler `add_positive_example()` quand workflow accepté et réussi
- Appeler `add_negative_example()` quand workflow rejeté
- Sauvegarder checkpoint à l'arrêt
- Charger checkpoint au démarrage
- _Requirements: 4.1, 4.2, 5.5_
- [x] 17. Ajouter logging et métriques
- Logger le début/fin du fine-tuning
- Logger les métriques (loss, accuracy, durée)
- Logger le nombre d'exemples collectés
- Créer fichier de log dédié `fine_tuning.log`
- _Requirements: 7.2, 7.3_
- [x] 18. Checkpoint Final - Tester le système complet
- Lancer l'application en mode Assist
- Accepter plusieurs workflows → vérifier collection d'exemples positifs
- Rejeter plusieurs workflows → vérifier collection d'exemples négatifs
- Attendre le trigger (10 exemples) → vérifier que fine-tuning démarre
- Vérifier que l'application continue de fonctionner pendant le fine-tuning
- Vérifier que les métriques sont loggées
- Vérifier que le modèle s'améliore après fine-tuning
- Ensure all tests pass, ask the user if questions arise.
## Phase 4: Optimisations et Outils
- [x] 19. Optimiser les performances
- Implémenter batch processing pour embed_batch()
- Optimiser le cache (utiliser hash plus rapide si nécessaire)
- Profiler les performances (temps, mémoire)
- Ajuster les paramètres si nécessaire
- _Requirements: 6.3, 6.4, 6.5_
- [ ]* 19.1 Écrire tests de performance
- Mesurer temps d'embedding (GPU vs CPU)
- Mesurer temps de recherche FAISS
- Mesurer temps de fine-tuning
- Vérifier que les seuils sont respectés
- _Requirements: 6.5_
- [x] 20. Créer outils de visualisation
- Créer script `visualize_embeddings.py`
- Utiliser t-SNE ou UMAP pour visualiser les embeddings
- Afficher les clusters de workflows similaires
- Comparer CLIP vs Pix2Struct visuellement
- _Requirements: 7.5_
- [x] 21. Créer outils de debugging
- Créer script `debug_embeddings.py`
- Afficher les embeddings pour une image donnée
- Afficher les résultats de recherche FAISS
- Afficher l'historique de fine-tuning
- _Requirements: 7.4, 7.5_
- [x] 22. Documentation finale
- Documenter l'architecture dans README
- Documenter comment choisir entre CLIP et Pix2Struct
- Documenter le système de fine-tuning
- Créer guide de troubleshooting
- _Requirements: All_
## Phase 5: Intégration dans l'Orchestrator
- [x] 23. Intégrer le système d'embeddings dans l'Orchestrator
- Créer méthode `_init_new_embedding_system()`
- Initialiser EmbeddingManager, FAISSIndex, LightweightFineTuner
- Charger les checkpoints au démarrage
- Gérer les erreurs d'initialisation
- _Requirements: All_
- [x] 24. Implémenter l'indexation automatique des workflows
- Créer méthode `_index_workflow_in_faiss()`
- Convertir screenshots en embeddings
- Indexer dans FAISS avec metadata
- Logger les opérations
- _Requirements: 1.1, 1.2, 1.3_
- [x] 25. Implémenter la collection d'exemples pour fine-tuning
- Créer méthode `_add_positive_example_for_finetuning()`
- Créer méthode `_add_negative_example_for_finetuning()`
- Connecter aux callbacks de suggestions
- Gérer la conversion d'images
- _Requirements: 4.1, 4.2, 5.1_
- [x] 26. Implémenter la sauvegarde à l'arrêt
- Créer méthode `_save_embedding_system_on_shutdown()`
- Attendre la fin du fine-tuning en cours
- Sauvegarder l'index FAISS
- Sauvegarder le checkpoint du fine-tuner
- Logger les statistiques
- _Requirements: 1.3, 5.5_
- [x] 27. Créer tests d'intégration
- Test d'initialisation du système
- Test d'indexation de workflows
- Test de collection d'exemples positifs/négatifs
- Test du cache
- Test de sauvegarde/chargement
- _Requirements: All_
- [x] 28. Créer script de vérification
- Vérifier l'installation de FAISS
- Vérifier l'import des modules
- Lancer les tests d'intégration
- Vérifier les fichiers créés
- Vérifier la documentation
- _Requirements: All_
- [x] 29. Documentation de l'intégration
- Créer EMBEDDING_SYSTEM_INTEGRATED.md
- Documenter l'architecture complète
- Documenter l'utilisation
- Documenter le monitoring
- Créer guide de troubleshooting
- _Requirements: All_
## Statut Final
✅ **INTÉGRATION COMPLÈTE**
Le système d'embeddings est maintenant complètement intégré dans GeniusIA v2 :
- ✅ Tous les composants sont implémentés
- ✅ Tous les tests passent
- ✅ La documentation est complète
- ✅ Le système est prêt pour la production
**Date de complétion** : 20 novembre 2024

495
.kiro/specs/faiss-learning-fix/design.md Normal file
View File

@@ -0,0 +1,495 @@
# Design Document - Correction Système d'Apprentissage FAISS
## Overview
Ce document décrit l'architecture de correction pour résoudre les problèmes critiques du système d'apprentissage RPA Vision V2. Après 3 jours de tests, le système ne génère aucune suggestion car l'index FAISS n'est jamais construit à partir des tâches sauvegardées. De plus, des processus zombies consomment 3GB+ RAM et l'application ne s'arrête pas proprement.
### Problèmes Identifiés
1. **Index FAISS vide** : L'index n'est jamais chargé au démarrage ni reconstruit à partir des tâches existantes
2. **Pas de chargement des tâches** : Les 19+ tâches sauvegardées ne sont jamais chargées dans l'index
3. **Processus zombies** : Les listeners pynput ne sont pas arrêtés proprement
4. **Fuite mémoire** : Boucles infinies et tensors GPU non libérés
5. **Pas de diagnostic** : Aucun outil pour comprendre l'état du système
### Solution Proposée
1. **Chargement automatique au démarrage** : Scanner et indexer toutes les tâches existantes
2. **Reconstruction d'index** : Commande pour reconstruire l'index à partir des tâches
3. **Arrêt propre** : Gestion correcte des threads et listeners
4. **Gestion mémoire** : Libération des ressources et circuit breakers
5. **Diagnostic complet** : Outil d'analyse de l'état du système
## Architecture
### Composants Modifiés
1. **EmbeddingsManager** : Ajout de méthodes de reconstruction et chargement
2. **LearningManager** : Chargement automatique des tâches au démarrage
3. **Orchestrator** : Arrêt propre des threads et listeners
4. **main.py** : Initialisation avec chargement des tâches existantes
### Nouveaux Composants
1. **FAISSIndexBuilder** : Construction et reconstruction de l'index
2. **SystemDiagnostic** : Diagnostic complet du système d'apprentissage
3. **MemoryMonitor** : Surveillance et gestion de la mémoire
4. **CircuitBreaker** : Protection contre les boucles infinies
## Components and Interfaces
### FAISSIndexBuilder
```python
class FAISSIndexBuilder:
"""Construit et reconstruit l'index FAISS à partir des tâches."""
def __init__(self, embeddings_manager, learning_manager, logger):
pass
def scan_tasks(self) -> List[TaskProfile]:
"""Scanne tous les dossiers de tâches."""
pass
def load_task_embeddings(self, task: TaskProfile) -> List[np.ndarray]:
"""Charge les embeddings d'une tâche."""
pass
def rebuild_index(self) -> Dict[str, Any]:
"""Reconstruit l'index complet."""
pass
def verify_index_integrity(self) -> bool:
"""Vérifie la cohérence de l'index."""
pass
```
### SystemDiagnostic
```python
class SystemDiagnostic:
"""Diagnostic complet du système d'apprentissage."""
def check_faiss_index(self) -> Dict[str, Any]:
"""Vérifie l'état de l'index FAISS."""
pass
def count_tasks(self) -> int:
"""Compte les tâches sauvegardées."""
pass
def check_consistency(self) -> Dict[str, Any]:
"""Vérifie la cohérence tâches/embeddings."""
pass
def generate_report(self) -> Dict[str, Any]:
"""Génère un rapport JSON complet."""
pass
```
### MemoryMonitor
```python
class MemoryMonitor:
"""Surveille et gère la consommation mémoire."""
def get_current_memory(self) -> float:
"""Retourne la mémoire utilisée en GB."""
pass
def check_threshold(self, max_memory_gb: float) -> bool:
"""Vérifie si le seuil est dépassé."""
pass
def cleanup_caches(self):
"""Nettoie les caches pour libérer de la mémoire."""
pass
def free_gpu_memory(self):
"""Libère la mémoire GPU."""
pass
```
### CircuitBreaker
```python
class CircuitBreaker:
"""Protection contre les boucles infinies."""
def __init__(self, threshold: int = 100, window: float = 1.0):
pass
def record_call(self, function_name: str):
"""Enregistre un appel de fonction."""
pass
def should_break(self, function_name: str) -> bool:
"""Vérifie si le circuit doit s'ouvrir."""
pass
def reset(self, function_name: str):
"""Réinitialise le circuit breaker."""
pass
```
## Data Models
### TaskEmbedding
```python
@dataclass
class TaskEmbedding:
"""Représente un embedding de tâche."""
task_id: str
embedding: np.ndarray
metadata: Dict[str, Any]
timestamp: datetime
```
### DiagnosticReport
```python
@dataclass
class DiagnosticReport:
"""Rapport de diagnostic du système."""
timestamp: datetime
faiss_index_exists: bool
faiss_index_size: int
tasks_count: int
embeddings_count: int
consistency_ok: bool
inconsistencies: List[str]
memory_usage_gb: float
recommendations: List[str]
```
### MemoryStats
```python
@dataclass
class MemoryStats:
"""Statistiques mémoire."""
total_mb: float
used_mb: float
available_mb: float
percent: float
gpu_used_mb: Optional[float]
```
## 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: Index chargé au démarrage
*For any* système qui démarre avec des tâches existantes, l'index FAISS doit contenir tous les embeddings de ces tâches après l'initialisation.
**Validates: Requirements 1.1**
### Property 2: Ajout immédiat à l'index
*For any* nouvelle tâche sauvegardée, ses embeddings doivent être immédiatement présents dans l'index FAISS.
**Validates: Requirements 1.2**
### Property 3: Persistance immédiate
*For any* modification de l'index FAISS, les fichiers sur disque doivent être mis à jour dans les 5 secondes.
**Validates: Requirements 1.3**
### Property 4: Reconstruction automatique
*For any* système qui détecte des tâches sans embeddings dans l'index, la reconstruction doit être déclenchée automatiquement.
**Validates: Requirements 1.4**
### Property 5: Suggestions avec index non-vide
*For any* action similaire à une tâche existante, si l'index contient des embeddings, une suggestion doit être retournée.
**Validates: Requirements 1.5**
### Property 6: Arrêt rapide
*For any* signal d'arrêt (Ctrl+C), tous les threads doivent être arrêtés en moins de 5 secondes.
**Validates: Requirements 2.1**
### Property 7: Libération mémoire
*For any* arrêt de l'application, la consommation mémoire du processus doit diminuer de plus de 90% dans les 10 secondes.
**Validates: Requirements 2.2**
### Property 8: Arrêt synchrone des threads
*For any* arrêt demandé, aucun thread de capture ne doit rester actif après la fin de la méthode shutdown().
**Validates: Requirements 2.3**
### Property 9: Stop explicite des listeners
*For any* listener pynput actif, sa méthode stop() doit être appelée avant la fin du programme.
**Validates: Requirements 2.4**
### Property 10: Threads daemon ou arrêt garanti
*For any* thread d'orchestrateur, il doit être soit daemon, soit avoir un mécanisme d'arrêt vérifié.
**Validates: Requirements 2.5**
### Property 11: Détection de patterns répétitifs
*For any* séquence de 3 actions identiques, un pattern doit être détecté et enregistré.
**Validates: Requirements 3.1**
### Property 12: Création de tâche après pattern
*For any* pattern détecté, une tâche avec signatures doit être créée dans les 2 secondes.
**Validates: Requirements 3.2**
### Property 13: Indexation des embeddings
*For any* tâche créée, ses embeddings multimodaux doivent être présents dans l'index FAISS.
**Validates: Requirements 3.3**
### Property 14: Suggestions avec confiance élevée
*For any* action similaire (similarité > 0.8) à une tâche existante, une suggestion avec confiance > 0.7 doit être proposée.
**Validates: Requirements 3.4**
### Property 15: Contenu des suggestions
*For any* suggestion affichée, elle doit contenir le nom de la tâche et la liste des actions à effectuer.
**Validates: Requirements 3.5**
### Property 16: Limite mémoire mode shadow
*For any* exécution en mode shadow pendant plus de 5 minutes, la consommation mémoire doit rester sous 1GB.
**Validates: Requirements 4.1**
### Property 17: Limite mémoire mode assist
*For any* exécution en mode assist pendant plus de 5 minutes, la consommation mémoire doit rester sous 2GB.
**Validates: Requirements 4.2**
### Property 18: Libération GPU
*For any* génération d'embedding, la mémoire GPU utilisée doit être libérée dans les 2 secondes.
**Validates: Requirements 4.3**
### Property 19: Buffer limité
*For any* moment de l'exécution, le buffer de screenshots ne doit jamais contenir plus de 10 images.
**Validates: Requirements 4.4**
### Property 20: Alerte mémoire
*For any* dépassement du seuil de 2GB, un avertissement doit être loggé et les caches nettoyés.
**Validates: Requirements 4.5**
### Property 21: Comptage des tâches
*For any* exécution du diagnostic, le nombre de tâches retourné doit correspondre au nombre de dossiers dans user_profiles.
**Validates: Requirements 5.2**
### Property 22: Vérification de cohérence
*For any* exécution du diagnostic, toutes les tâches avec embeddings doivent avoir leurs embeddings dans l'index.
**Validates: Requirements 5.3**
### Property 23: Proposition de reconstruction
*For any* incohérence détectée (tâche sans embedding dans l'index), le diagnostic doit proposer une reconstruction.
**Validates: Requirements 5.4**
### Property 24: Rapport JSON complet
*For any* diagnostic terminé, un fichier JSON doit être généré avec toutes les métriques requises.
**Validates: Requirements 5.5**
### Property 25: Scan complet des tâches
*For any* reconstruction lancée, tous les dossiers de tâches existants doivent être scannés.
**Validates: Requirements 6.1**
### Property 26: Génération d'embeddings manquants
*For any* tâche trouvée sans embeddings dans l'index, les embeddings doivent être générés et ajoutés.
**Validates: Requirements 6.2**
### Property 27: Construction d'index optimisé
*For any* reconstruction terminée, un nouvel index FAISS doit être créé avec tous les embeddings.
**Validates: Requirements 6.3**
### Property 28: Sauvegarde après reconstruction
*For any* reconstruction réussie, les fichiers d'index et métadonnées doivent être sauvegardés sur disque.
**Validates: Requirements 6.4**
### Property 29: Résilience aux erreurs
*For any* erreur lors du traitement d'une tâche, la reconstruction doit continuer avec les tâches suivantes.
**Validates: Requirements 6.5**
### Property 30: Validation norme non-nulle
*For any* embedding généré, sa norme L2 doit être strictement positive.
**Validates: Requirements 7.1**
### Property 31: Validation NaN/Inf
*For any* embedding généré, il ne doit contenir ni NaN ni Inf.
**Validates: Requirements 7.2**
### Property 32: Cohérence embeddings identiques
*For any* paire de screenshots identiques, leurs embeddings doivent avoir une similarité cosinus > 0.95.
**Validates: Requirements 7.3**
### Property 33: Discrimination embeddings différents
*For any* paire de screenshots visuellement différents, leurs embeddings doivent avoir une similarité cosinus < 0.8.
**Validates: Requirements 7.4**
### Property 34: Régénération sur invalide
*For any* embedding invalide détecté, une erreur doit être loggée et l'embedding régénéré.
**Validates: Requirements 7.5**
### Property 35: Activation circuit breaker
*For any* fonction appelée plus de 100 fois en 1 seconde, le circuit breaker doit s'activer.
**Validates: Requirements 8.1**
### Property 36: Log circuit breaker
*For any* activation de circuit breaker, un log avec stack trace doit être créé.
**Validates: Requirements 8.2**
### Property 37: Blocage temporaire
*For any* circuit breaker activé, la fonction doit être bloquée pendant 60 secondes.
**Validates: Requirements 8.3**
### Property 38: Reprise progressive
*For any* réinitialisation de circuit breaker, un rate limit doit être appliqué à la reprise.
**Validates: Requirements 8.4**
### Property 39: Mode dégradé
*For any* situation avec 3 circuit breakers actifs simultanément, le système doit passer en mode dégradé.
**Validates: Requirements 8.5**
## Error Handling
### Stratégie Générale
1. **Erreurs de chargement** : Logger et continuer avec les tâches suivantes
2. **Erreurs d'embedding** : Régénérer jusqu'à 3 tentatives
3. **Erreurs FAISS** : Reconstruire l'index si corrompu
4. **Erreurs mémoire** : Nettoyer les caches et alerter
5. **Erreurs de thread** : Forcer l'arrêt après timeout
### Gestion des Erreurs Critiques
```python
try:
# Opération critique
pass
except MemoryError:
memory_monitor.cleanup_caches()
logger.log_critical("memory_exhausted")
except FAISSError:
index_builder.rebuild_index()
logger.log_critical("faiss_corrupted")
except ThreadError:
force_shutdown_threads()
logger.log_critical("thread_deadlock")
```
## Testing Strategy
### Unit Tests
- Test de chargement des tâches individuelles
- Test de génération d'embeddings
- Test d'ajout à l'index FAISS
- Test de recherche de similarité
- Test d'arrêt des threads
- Test de libération mémoire
### Property-Based Tests
Nous utiliserons **Hypothesis** pour Python comme bibliothèque de property-based testing. Chaque test sera configuré pour exécuter au minimum 100 itérations.
Chaque property-based test doit être tagué avec un commentaire référençant explicitement la correctness property du design document au format : `**Feature: faiss-learning-fix, Property {number}: {property_text}**`
Les tests doivent couvrir :
- Génération aléatoire de tâches et vérification de l'indexation
- Génération aléatoire d'embeddings et validation
- Simulation d'arrêts à différents moments
- Simulation de charges mémoire variables
- Simulation d'appels répétitifs pour circuit breakers
### Integration Tests
- Test du flux complet : création tâche → indexation → suggestion
- Test de reconstruction d'index avec tâches existantes
- Test d'arrêt propre avec tous les composants actifs
- Test de diagnostic sur système réel
- Test de gestion mémoire sous charge
## Implementation Notes
### Ordre d'Implémentation
1. **FAISSIndexBuilder** : Fondation pour tout le reste
2. **Chargement au démarrage** : Correction immédiate du problème principal
3. **Arrêt propre** : Correction des processus zombies
4. **MemoryMonitor** : Protection contre les fuites
5. **CircuitBreaker** : Protection contre les boucles
6. **SystemDiagnostic** : Outil de débogage
### Points d'Attention
1. **Compatibilité** : Ne pas casser le code existant
2. **Performance** : Chargement rapide au démarrage (<10s)
3. **Robustesse** : Gérer les tâches corrompues
4. **Logs** : Tracer toutes les opérations critiques
5. **Tests** : Valider chaque property avant de continuer

115
.kiro/specs/faiss-learning-fix/requirements.md Normal file
View File

@@ -0,0 +1,115 @@
# Requirements Document - Correction Système d'Apprentissage FAISS
## Introduction
Le système RPA Vision V2 présente des défaillances critiques dans son système d'apprentissage. Après 3 jours de tests répétitifs (calculatrice, OnlyOffice), aucune suggestion n'est générée malgré la présence de 19+ tâches sauvegardées. L'index FAISS reste vide, les processus zombies consomment 3GB+ RAM, et le système ne peut pas être arrêté proprement.
## Glossaire
- **FAISS**: Facebook AI Similarity Search - Bibliothèque pour la recherche de similarité vectorielle
- **Index FAISS**: Structure de données contenant les embeddings pour la recherche rapide
- **Embedding**: Représentation vectorielle d'une capture d'écran ou action
- **Tâche**: Séquence d'actions utilisateur sauvegardée avec ses signatures
- **Signature**: Représentation unique d'une action (screenshot + embedding + métadonnées)
- **LearningManager**: Composant responsable de la détection et sauvegarde des patterns
- **EmbeddingsManager**: Composant responsable de la gestion de l'index FAISS
- **Processus zombie**: Processus qui continue de s'exécuter après l'arrêt demandé
- **Circuit breaker**: Mécanisme de protection contre les boucles infinies
## Requirements
### Requirement 1
**User Story:** En tant qu'utilisateur, je veux que le système construise automatiquement l'index FAISS à partir des tâches sauvegardées, afin que les suggestions fonctionnent après mes tests répétitifs.
#### Acceptance Criteria
1. WHEN le système démarre THEN le système SHALL charger toutes les tâches existantes dans l'index FAISS
2. WHEN une nouvelle tâche est sauvegardée THEN le système SHALL ajouter immédiatement ses embeddings à l'index FAISS
3. WHEN l'index FAISS est modifié THEN le système SHALL persister l'index sur disque immédiatement
4. WHEN le système détecte des tâches sans embeddings dans l'index THEN le système SHALL reconstruire l'index complet
5. WHEN l'index FAISS contient des embeddings THEN le système SHALL retourner des suggestions pour des actions similaires
### Requirement 2
**User Story:** En tant qu'utilisateur, je veux que l'application s'arrête proprement sans laisser de processus zombies, afin de ne pas avoir à tuer manuellement des processus consommant 3GB+ RAM.
#### Acceptance Criteria
1. WHEN l'utilisateur appuie sur Ctrl+C THEN le système SHALL arrêter tous les threads en moins de 5 secondes
2. WHEN l'application s'arrête THEN le système SHALL libérer toute la mémoire allouée
3. WHEN des threads de capture sont actifs THEN le système SHALL les arrêter de manière synchrone avant de quitter
4. WHEN pynput listeners sont actifs THEN le système SHALL appeler explicitement leur méthode stop()
5. WHEN l'orchestrateur tourne en arrière-plan THEN le système SHALL utiliser des threads daemon ou un mécanisme d'arrêt garanti
### Requirement 3
**User Story:** En tant qu'utilisateur, je veux voir des suggestions après avoir effectué des actions répétitives, afin que le système apprenne réellement de mes comportements.
#### Acceptance Criteria
1. WHEN l'utilisateur effectue la même action 3 fois THEN le système SHALL détecter le pattern répétitif
2. WHEN un pattern est détecté THEN le système SHALL créer une tâche avec ses signatures
3. WHEN une tâche est créée THEN le système SHALL générer et indexer les embeddings multimodaux
4. WHEN l'utilisateur effectue une action similaire à une tâche existante THEN le système SHALL proposer une suggestion avec confiance > 0.7
5. WHEN une suggestion est affichée THEN le système SHALL inclure le nom de la tâche et les actions à effectuer
### Requirement 4
**User Story:** En tant qu'utilisateur, je veux que le système ne consomme pas plus de 2GB de RAM en fonctionnement normal, afin d'éviter les fuites mémoire.
#### Acceptance Criteria
1. WHEN le système fonctionne en mode shadow THEN la consommation mémoire SHALL rester sous 1GB
2. WHEN le système fonctionne en mode assist THEN la consommation mémoire SHALL rester sous 2GB
3. WHEN des embeddings sont générés THEN le système SHALL libérer les tensors GPU après utilisation
4. WHEN des screenshots sont capturés THEN le système SHALL limiter la taille du buffer à 10 images maximum
5. WHEN la mémoire dépasse 2GB THEN le système SHALL logger un avertissement et nettoyer les caches
### Requirement 5
**User Story:** En tant qu'utilisateur, je veux un diagnostic complet du système d'apprentissage, afin de comprendre pourquoi aucune suggestion n'apparaît après 3 jours de tests.
#### Acceptance Criteria
1. WHEN l'utilisateur lance le diagnostic THEN le système SHALL vérifier l'existence et la taille de l'index FAISS
2. WHEN le diagnostic s'exécute THEN le système SHALL compter le nombre de tâches sauvegardées
3. WHEN le diagnostic s'exécute THEN le système SHALL vérifier la cohérence entre tâches et embeddings indexés
4. WHEN des incohérences sont détectées THEN le système SHALL proposer une reconstruction automatique
5. WHEN le diagnostic se termine THEN le système SHALL générer un rapport JSON avec toutes les métriques
### Requirement 6
**User Story:** En tant qu'utilisateur, je veux une commande de reconstruction de l'index FAISS, afin de réparer le système sans perdre mes 3 jours de tests.
#### Acceptance Criteria
1. WHEN l'utilisateur lance la reconstruction THEN le système SHALL scanner tous les dossiers de tâches
2. WHEN une tâche est trouvée THEN le système SHALL charger ses signatures et générer les embeddings manquants
3. WHEN tous les embeddings sont générés THEN le système SHALL construire un nouvel index FAISS optimisé
4. WHEN la reconstruction est terminée THEN le système SHALL sauvegarder l'index et les métadonnées
5. WHEN la reconstruction échoue THEN le système SHALL logger l'erreur et continuer avec les tâches suivantes
### Requirement 7
**User Story:** En tant qu'utilisateur, je veux que le système valide la qualité des embeddings générés, afin de garantir que les suggestions seront pertinentes.
#### Acceptance Criteria
1. WHEN un embedding est généré THEN le système SHALL vérifier que sa norme est non-nulle
2. WHEN un embedding est généré THEN le système SHALL vérifier qu'il ne contient pas de NaN ou Inf
3. WHEN deux screenshots identiques sont traités THEN leurs embeddings SHALL avoir une similarité > 0.95
4. WHEN deux screenshots différents sont traités THEN leurs embeddings SHALL avoir une similarité < 0.8
5. WHEN un embedding invalide est détecté THEN le système SHALL logger l'erreur et régénérer l'embedding
### Requirement 8
**User Story:** En tant qu'utilisateur, je veux que le système détecte et corrige automatiquement les boucles infinies, afin d'éviter les fuites mémoire de 3GB+.
#### Acceptance Criteria
1. WHEN une fonction est appelée plus de 100 fois par seconde THEN le système SHALL activer un circuit breaker
2. WHEN un circuit breaker est activé THEN le système SHALL logger l'événement avec la stack trace
3. WHEN un circuit breaker est activé THEN le système SHALL arrêter temporairement la fonction pendant 60 secondes
4. WHEN le circuit breaker se réinitialise THEN le système SHALL reprendre progressivement avec un rate limit
5. WHEN 3 circuit breakers sont activés simultanément THEN le système SHALL passer en mode dégradé et alerter l'utilisateur

190
.kiro/specs/faiss-learning-fix/tasks.md Normal file
View File

@@ -0,0 +1,190 @@
# Implementation Plan - Correction Système d'Apprentissage FAISS
## Objectif
Corriger les problèmes critiques du système d'apprentissage : index FAISS vide malgré 19+ tâches sauvegardées, processus zombies consommant 3GB+ RAM, et absence de suggestions après 3 jours de tests.
## Tasks
- [x] 1. Créer le FAISSIndexBuilder pour reconstruction d'index ✅ TERMINÉ
- Créer `geniusia2/core/faiss_index_builder.py`
- Implémenter `scan_tasks()` pour scanner tous les dossiers de tâches
- Implémenter `load_task_embeddings()` pour charger les embeddings depuis les signatures.pkl
- Implémenter `rebuild_index()` pour reconstruire l'index complet
- Implémenter `verify_index_integrity()` pour vérifier la cohérence
- _Requirements: 1.4, 6.1, 6.2, 6.3, 6.4, 6.5_
- **Résultat: 40 tâches scannées, 122 embeddings indexés**
- [ ]* 1.1 Écrire les property tests pour FAISSIndexBuilder
- **Property 25: Scan complet des tâches**
- **Property 26: Génération d'embeddings manquants**
- **Property 27: Construction d'index optimisé**
- **Property 28: Sauvegarde après reconstruction**
- **Property 29: Résilience aux erreurs**
- **Validates: Requirements 6.1, 6.2, 6.3, 6.4, 6.5**
- [x] 2. Implémenter le chargement automatique au démarrage ✅ TERMINÉ
- Modifier `geniusia2/core/learning_manager.py` pour charger les tâches existantes dans `__init__`
- Utiliser FAISSIndexBuilder pour reconstruire l'index si vide
- Ajouter logs pour tracer le chargement
- Gérer les erreurs de chargement (tâches corrompues)
- _Requirements: 1.1, 1.2, 1.3_
- **Résultat: 40 tâches chargées, 672 workflows détectés**
- [ ]* 2.1 Écrire les property tests pour chargement automatique
- **Property 1: Index chargé au démarrage**
- **Property 2: Ajout immédiat à l'index**
- **Property 3: Persistance immédiate**
- **Property 4: Reconstruction automatique**
- **Validates: Requirements 1.1, 1.2, 1.3, 1.4**
- [x] 3. Corriger l'arrêt propre des processus ✅ TERMINÉ
- Modifier `geniusia2/main.py` méthode `shutdown()` pour arrêter explicitement les listeners pynput
- Ajouter timeout de 5 secondes pour l'arrêt des threads
- Implémenter arrêt synchrone des threads de capture
- Forcer l'arrêt si timeout dépassé
- Vérifier que tous les threads sont bien arrêtés
- _Requirements: 2.1, 2.3, 2.4, 2.5_
- **Résultat: Arrêt propre en <5s, aucun processus zombie**
- [ ]* 3.1 Écrire les property tests pour arrêt propre
- **Property 6: Arrêt rapide**
- **Property 8: Arrêt synchrone des threads**
- **Property 9: Stop explicite des listeners**
- **Property 10: Threads daemon ou arrêt garanti**
- **Validates: Requirements 2.1, 2.3, 2.4, 2.5**
- [x] 4. Checkpoint - Vérifier que le système charge les tâches et s'arrête proprement ✅ VALIDÉ
- Lancer le système avec les 40 tâches existantes
- Vérifier que l'index FAISS contient les embeddings
- Tester l'arrêt avec Ctrl+C
- Vérifier qu'aucun processus zombie ne reste
- Mesurer la consommation mémoire
- **Résultat: Tous les tests passés, système stable et fonctionnel**
- [ ] 5. Créer le MemoryMonitor pour gestion mémoire
- Créer `geniusia2/core/memory_monitor.py`
- Implémenter `get_current_memory()` pour mesurer la RAM utilisée
- Implémenter `check_threshold()` pour vérifier les seuils
- Implémenter `cleanup_caches()` pour libérer la mémoire
- Implémenter `free_gpu_memory()` pour libérer la mémoire GPU
- Intégrer dans l'orchestrateur avec vérification périodique
- _Requirements: 4.1, 4.2, 4.3, 4.4, 4.5_
- [ ]* 5.1 Écrire les property tests pour MemoryMonitor
- **Property 16: Limite mémoire mode shadow**
- **Property 17: Limite mémoire mode assist**
- **Property 18: Libération GPU**
- **Property 19: Buffer limité**
- **Property 20: Alerte mémoire**
- **Validates: Requirements 4.1, 4.2, 4.3, 4.4, 4.5**
- [ ] 6. Créer le CircuitBreaker pour protection contre boucles infinies
- Créer `geniusia2/core/circuit_breaker.py`
- Implémenter détection d'appels répétitifs (>100/s)
- Implémenter blocage temporaire (60s)
- Implémenter reprise progressive avec rate limit
- Implémenter mode dégradé si 3 breakers actifs
- Intégrer dans les fonctions critiques (check_for_suggestions, etc.)
- _Requirements: 8.1, 8.2, 8.3, 8.4, 8.5_
- [ ]* 6.1 Écrire les property tests pour CircuitBreaker
- **Property 35: Activation circuit breaker**
- **Property 36: Log circuit breaker**
- **Property 37: Blocage temporaire**
- **Property 38: Reprise progressive**
- **Property 39: Mode dégradé**
- **Validates: Requirements 8.1, 8.2, 8.3, 8.4, 8.5**
- [ ] 7. Créer le SystemDiagnostic pour analyse du système
- Créer `geniusia2/core/system_diagnostic.py`
- Implémenter `check_faiss_index()` pour vérifier l'index
- Implémenter `count_tasks()` pour compter les tâches
- Implémenter `check_consistency()` pour vérifier cohérence tâches/embeddings
- Implémenter `generate_report()` pour créer un rapport JSON
- Créer script CLI `diagnostic_systeme.py` à la racine
- _Requirements: 5.1, 5.2, 5.3, 5.4, 5.5_
- [ ]* 7.1 Écrire les property tests pour SystemDiagnostic
- **Property 21: Comptage des tâches**
- **Property 22: Vérification de cohérence**
- **Property 23: Proposition de reconstruction**
- **Property 24: Rapport JSON complet**
- **Validates: Requirements 5.2, 5.3, 5.4, 5.5**
- [ ] 8. Améliorer la validation des embeddings
- Modifier `geniusia2/core/embeddings_manager.py` méthode `encode_image()`
- Ajouter validation de la norme (doit être > 0)
- Ajouter validation NaN/Inf
- Ajouter régénération automatique si invalide
- Ajouter tests de cohérence (screenshots identiques → similarité > 0.95)
- _Requirements: 7.1, 7.2, 7.3, 7.4, 7.5_
- [ ]* 8.1 Écrire les property tests pour validation embeddings
- **Property 30: Validation norme non-nulle**
- **Property 31: Validation NaN/Inf**
- **Property 32: Cohérence embeddings identiques**
- **Property 33: Discrimination embeddings différents**
- **Property 34: Régénération sur invalide**
- **Validates: Requirements 7.1, 7.2, 7.3, 7.4, 7.5**
- [ ] 9. Améliorer le système de suggestions
- Modifier `geniusia2/core/suggestion_manager.py`
- Vérifier que l'index n'est pas vide avant recherche
- S'assurer que les suggestions incluent nom de tâche et actions
- Ajouter seuil de confiance minimum (0.7)
- Ajouter logs pour tracer les suggestions
- _Requirements: 1.5, 3.4, 3.5_
- [ ]* 9.1 Écrire les property tests pour suggestions
- **Property 5: Suggestions avec index non-vide**
- **Property 14: Suggestions avec confiance élevée**
- **Property 15: Contenu des suggestions**
- **Validates: Requirements 1.5, 3.4, 3.5**
- [ ] 10. Améliorer la détection de patterns
- Modifier `geniusia2/core/learning_manager.py`
- Implémenter détection de 3 actions identiques
- Créer automatiquement une tâche après détection
- Indexer immédiatement les embeddings
- Ajouter logs pour tracer la détection
- _Requirements: 3.1, 3.2, 3.3_
- [ ]* 10.1 Écrire les property tests pour détection patterns
- **Property 11: Détection de patterns répétitifs**
- **Property 12: Création de tâche après pattern**
- **Property 13: Indexation des embeddings**
- **Validates: Requirements 3.1, 3.2, 3.3**
- [ ] 11. Créer un script de reconstruction manuelle
- Créer `rebuild_faiss_index.py` à la racine
- Utiliser FAISSIndexBuilder pour reconstruire
- Afficher la progression (tâches traitées)
- Générer un rapport de reconstruction
- Sauvegarder l'index et métadonnées
- _Requirements: 6.1, 6.2, 6.3, 6.4, 6.5_
- [ ] 12. Créer un script de test de mémoire
- Créer `test_memory_limits.py` à la racine
- Tester mode shadow pendant 10 minutes
- Tester mode assist pendant 10 minutes
- Mesurer la consommation mémoire toutes les 30 secondes
- Vérifier les seuils (1GB shadow, 2GB assist)
- Générer un rapport de consommation
- _Requirements: 4.1, 4.2_
- [ ] 13. Checkpoint final - Validation complète
- Exécuter le diagnostic complet
- Reconstruire l'index avec les 19+ tâches
- Tester les suggestions avec actions répétitives
- Vérifier l'arrêt propre (pas de zombies)
- Vérifier la consommation mémoire (<2GB)
- Vérifier les circuit breakers
- Ensure all tests pass, ask the user if questions arise.
- [ ] 14. Documentation et nettoyage
- Créer `GUIDE_CORRECTION_FAISS.md` expliquant les corrections
- Documenter l'utilisation du diagnostic
- Documenter l'utilisation de la reconstruction
- Mettre à jour le README avec les nouvelles commandes
- Nettoyer les anciens scripts de diagnostic

400
.kiro/specs/gui-logs-improvement/design.md Normal file
View File

@@ -0,0 +1,400 @@
# Design - Amélioration GUI et Logs
## Overview
Ce document décrit l'architecture et le design de la nouvelle interface utilisateur minimaliste et du système de logs amélioré pour GeniusIA v2.
## Architecture
```
┌─────────────────────────────────────────────────────────┐
│ Main Application │
└────────────────┬────────────────────────────────────────┘
│
┌────────┴────────┐
▼ ▼
┌──────────────┐ ┌──────────────────┐
│ Orchestrator │ │ Improved GUI │
│ │ │ │
│ - Détecte │──│ - System Tray │
│ - Apprend │ │ - Logs Panel │
│ - Suggère │ │ - Popups │
└──────┬───────┘ └──────────────────┘
│
▼
┌──────────────┐
│ HumanLogger │
│ │
│ - Messages │
│ - Formatting │
└──────────────┘
```
## Components and Interfaces
### 1. HumanLogger
Classe pour générer des messages lisibles par l'utilisateur.
```python
class HumanLogger:
"""
Logger qui génère des messages simples pour l'utilisateur.
"""
def log_observation(self, action_type: str, window: str):
"""Log une action observée."""
return f"👀 Action dans {window}"
def log_pattern_detected(self, repetitions: int, task_name: str):
"""Log un pattern détecté."""
return f"🎯 Pattern détecté: {task_name} (répété {repetitions}x)"
def log_workflow_learned(self, task_name: str, count: int):
"""Log un workflow appris."""
return f"📚 Workflow appris: {task_name} ({count} observations)"
def log_mode_change(self, old_mode: str, new_mode: str):
"""Log un changement de mode."""
return f"✅ Mode {new_mode} activé"
def log_finetuning_started(self, num_examples: int):
"""Log le début du fine-tuning."""
return f"🧠 Amélioration du modèle ({num_examples} exemples)..."
def log_finetuning_completed(self, duration: float):
"""Log la fin du fine-tuning."""
return f"✅ Modèle amélioré (en {duration:.1f}s)"
```
### 2. ImprovedGUI
Interface minimaliste avec system tray.
#### Layout Principal
```
┌─────────────────────────────────────┐
│ GeniusIA v2 [_][X]│
├─────────────────────────────────────┤
│ │
│ Mode: 👀 Observation │
│ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ │
│ │
│ 📊 Activité: │
│ • 12 actions observées │
│ • 2 patterns détectés │
│ │
│ 🧠 Fine-tuning: │
│ • 8/10 exemples collectés │
│ │
├─────────────────────────────────────┤
│ 📝 Journal: │
│ ┌─────────────────────────────────┐│
│ │14:23 👀 J'observe... ││
│ │14:24 🎯 Pattern: Calculer 9/9 ││
│ │14:24 📚 J'apprends... ││
│ │14:25 💡 Prêt à suggérer ││
│ │14:26 ✅ Mode Suggestions activé ││
│ └─────────────────────────────────┘│
│ │
│ [Pause] [Arrêter] │
└─────────────────────────────────────┘
```
#### System Tray
```
Icône dans la barre: 🤖
Menu clic droit:
┌─────────────────────┐
│ 🤖 GeniusIA v2 │
├─────────────────────┤
│ 👀 Mode: Shadow │
│ 📊 12 actions │
├─────────────────────┤
│ Afficher │
│ Masquer │
│ ───────────────── │
│ Quitter │
└─────────────────────┘
```
#### Popup Interactif
```
┌─────────────────────────────────────────┐
│ 💡 J'ai une idée ! │
│ │
│ J'ai remarqué que vous faites souvent: │
│ "Calculer 9/9 dans la calculatrice" │
│ │
│ Est-ce que je peux essayer de vous │
│ suggérer cette action la prochaine │
│ fois ? │
│ │
│ [Oui, essaie !] [Non, continue] │
│ │
│ ⏱️ Fermeture auto dans 10s │
└─────────────────────────────────────────┘
```
### 3. LogsPanel
Widget pour afficher les logs avec scroll.
```python
class LogsPanel(QWidget):
"""
Panneau d'affichage des logs avec scroll.
- Affiche 5 dernières actions
- Scrollable jusqu'à 30
- Auto-scroll si en bas
- Format: HH:MM emoji Message
"""
def add_log(self, message: str, emoji: str = "ℹ️"):
"""Ajoute un log avec timestamp."""
pass
def clear(self):
"""Efface tous les logs."""
pass
def get_logs(self) -> List[str]:
"""Retourne l'historique."""
pass
```
### 4. InteractiveDialog
Popup pour dialogues avec timeout.
```python
class InteractiveDialog(QDialog):
"""
Dialogue interactif avec timeout automatique.
- Non-bloquant (l'app continue)
- Timeout 10 secondes
- Callbacks pour réponses
"""
def __init__(
self,
title: str,
message: str,
on_accept: Callable,
on_reject: Callable,
timeout: int = 10
):
pass
```
## Data Models
### LogMessage
```python
@dataclass
class LogMessage:
"""Message de log pour affichage."""
timestamp: datetime
emoji: str
message: str
level: str # 'info', 'success', 'warning', 'error'
technical_details: Optional[str] = None # Pour logs techniques
```
### GUIState
```python
@dataclass
class GUIState:
"""État de la GUI."""
mode: str # 'shadow', 'assist', 'auto'
is_running: bool
actions_count: int
patterns_count: int
workflows_count: int
finetuning_status: Optional[str] # None, 'collecting', 'training', 'completed'
finetuning_progress: Optional[int] # 0-100 ou None
```
## Error Handling
### Erreurs GUI
- **Erreur d'affichage** : Logger et continuer sans GUI
- **Erreur system tray** : Fallback vers fenêtre normale
- **Erreur popup** : Logger et utiliser notification simple
### Erreurs Logs
- **Fichier de log inaccessible** : Créer nouveau fichier avec timestamp
- **Disque plein** : Nettoyer anciens logs automatiquement
- **Permission refusée** : Logger dans /tmp en fallback
## Testing Strategy
### Unit Tests
- Test HumanLogger : Vérifier format des messages
- Test LogsPanel : Vérifier scroll et limite 30
- Test InteractiveDialog : Vérifier timeout
- Test GUIState : Vérifier mise à jour
### Integration Tests
- Test Orchestrator → GUI : Vérifier envoi de messages
- Test Popup → Orchestrator : Vérifier callbacks
- Test System Tray : Vérifier menu et actions
### Manual Tests
- Test sur Ubuntu : Vérifier system tray et thème
- Test avec actions répétitives : Vérifier détection
- Test timeout : Vérifier fermeture auto après 10s
## Correctness Properties
*A property is a characteristic or behavior that should hold true across all valid executions of a system.*
### Property 1: Log History Bounds
*For any* sequence of log messages, the visible history should never exceed 30 messages.
**Validates: Requirements 3.3**
### Property 2: Timeout Consistency
*For any* interactive dialog, if no user response is received within 10 seconds, the dialog should close automatically.
**Validates: Requirements 4.3**
### Property 3: Mode Display Consistency
*For any* mode change, the GUI should display the correct mode icon and label within 100ms.
**Validates: Requirements 5.1**
### Property 4: Message Ordering
*For any* sequence of events, the logs should appear in chronological order.
**Validates: Requirements 2.1, 2.2, 2.3, 2.4**
### Property 5: Non-blocking Dialogs
*For any* interactive dialog displayed, the Orchestrator should continue processing events.
**Validates: Requirements 4.2**
## Implementation Notes
### PyQt5 Signals
Utiliser des signaux Qt pour communication thread-safe :
```python
class GUISignals(QObject):
"""Signaux pour communication Orchestrator → GUI."""
log_message = pyqtSignal(str, str) # (emoji, message)
update_stats = pyqtSignal(dict) # GUIState
show_dialog = pyqtSignal(str, str, object, object) # (title, msg, on_accept, on_reject)
mode_changed = pyqtSignal(str) # nouveau mode
```
### System Tray Ubuntu
Utiliser `QSystemTrayIcon` avec fallback si non supporté :
```python
if QSystemTrayIcon.isSystemTrayAvailable():
self.tray_icon = QSystemTrayIcon(QIcon.fromTheme("robot"))
self.tray_icon.setToolTip("GeniusIA v2")
else:
# Fallback: fenêtre normale
self.setWindowFlags(Qt.Window)
```
### Logs Techniques
Format structuré pour parsing facile :
```
2024-11-20 14:23:45.123 [INFO] EventCapture: Mouse click at (450, 320) in "Calculator"
2024-11-20 14:23:46.456 [DEBUG] SessionManager: Action added to session_001
2024-11-20 14:24:12.789 [INFO] WorkflowDetector: Pattern detected (3 repetitions)
```
### Performance
- Logs GUI : Max 30 messages en mémoire
- Logs fichier : Rotation à 10MB
- Mise à jour GUI : Max 10 fois/seconde
- Popups : Timeout 10s pour éviter accumulation
## UI/UX Considerations
### Discrétion
- Fenêtre petite (300x400px)
- Minimisable
- System tray toujours visible
- Pas de sons
### Clarté
- Messages courts (max 50 caractères)
- Emojis pour reconnaissance rapide
- Couleurs pour niveaux (info/success/warning/error)
- Timestamps relatifs ("il y a 2 min")
### Réactivité
- Mise à jour en temps réel
- Pas de freeze
- Feedback immédiat sur actions
## Migration Plan
### Phase 1: Créer nouveaux composants
1. HumanLogger
2. ImprovedGUI
3. LogsPanel
4. InteractiveDialog
### Phase 2: Modifier Orchestrator
1. Ajouter envoi de messages humains
2. Connecter aux signaux GUI
3. Déclencher dialogues interactifs
### Phase 3: Remplacer ancienne GUI
1. Renommer `minimal_gui.py` → `minimal_gui_old.py`
2. Renommer `improved_gui.py` → `minimal_gui.py`
3. Tester
### Phase 4: Cleanup
1. Supprimer anciens boutons (liste blanche, etc.)
2. Supprimer code inutilisé
3. Documentation
## Security Considerations
- Logs techniques : Ne pas logger de données sensibles
- Popups : Timeout pour éviter DOS
- System tray : Vérifier permissions Ubuntu
## Accessibility
- Contraste suffisant pour lisibilité
- Taille de police ajustable
- Support clavier complet
- Screen reader compatible (ARIA labels)

137
.kiro/specs/gui-logs-improvement/requirements.md Normal file
View File

@@ -0,0 +1,137 @@
# Requirements - Amélioration GUI et Logs
## Introduction
GeniusIA v2 nécessite une interface utilisateur claire et des logs lisibles pour permettre à l'utilisateur de comprendre ce qui se passe et faciliter le debugging. L'interface actuelle manque de visibilité et les logs sont trop techniques.
## Glossary
- **GUI**: Interface graphique utilisateur (Graphical User Interface)
- **System Tray**: Zone de notification dans la barre des tâches (Ubuntu)
- **Popup**: Fenêtre modale temporaire pour dialogues
- **Human Logs**: Messages simples destinés à l'utilisateur
- **Technical Logs**: Logs détaillés pour debugging
- **Mode**: État opérationnel (Shadow/Suggestions/Copilote/Autonome)
- **Fine-tuning**: Processus d'amélioration du modèle d'embeddings
## Requirements
### Requirement 1: Interface Minimaliste
**User Story:** En tant qu'utilisateur, je veux une interface discrète qui ne me dérange pas, pour pouvoir travailler normalement tout en gardant un œil sur l'IA.
#### Acceptance Criteria
1. WHEN l'application démarre THEN la GUI SHALL créer une fenêtre de 300x400 pixels maximum
2. WHEN l'utilisateur clique sur minimiser THEN la GUI SHALL se réduire dans la barre des tâches Ubuntu
3. WHEN l'application tourne THEN la GUI SHALL afficher une icône dans le system tray
4. WHEN l'utilisateur clique sur l'icône system tray THEN la GUI SHALL afficher un menu avec options (Afficher/Masquer/Quitter)
5. WHEN la fenêtre est fermée THEN l'application SHALL continuer à tourner en arrière-plan
### Requirement 2: Logs Humains Lisibles
**User Story:** En tant qu'utilisateur, je veux voir ce que l'IA fait en langage simple, pour comprendre son comportement sans jargon technique.
#### Acceptance Criteria
1. WHEN une action est observée THEN la GUI SHALL afficher un message simple comme "👀 J'observe vos actions..."
2. WHEN un pattern est détecté THEN la GUI SHALL afficher "🎯 Tiens ! Vous avez fait 3 fois la même chose"
3. WHEN un workflow est appris THEN la GUI SHALL afficher "📚 J'apprends: [nom du workflow]"
4. WHEN le mode change THEN la GUI SHALL afficher "✅ Mode [nouveau mode] activé"
5. WHEN une erreur survient THEN la GUI SHALL afficher un message compréhensible sans stack trace
### Requirement 3: Historique des Logs
**User Story:** En tant qu'utilisateur, je veux voir les dernières actions pour comprendre ce qui s'est passé récemment.
#### Acceptance Criteria
1. WHEN des logs sont affichés THEN la GUI SHALL montrer les 5 dernières actions visibles
2. WHEN l'utilisateur scrolle THEN la GUI SHALL permettre de voir jusqu'à 30 actions
3. WHEN l'historique dépasse 30 actions THEN le système SHALL supprimer les plus anciennes
4. WHEN un nouveau log arrive THEN la GUI SHALL auto-scroller vers le bas si déjà en bas
5. WHEN l'utilisateur scrolle manuellement THEN la GUI SHALL ne pas auto-scroller
### Requirement 4: Dialogues Interactifs
**User Story:** En tant qu'utilisateur, je veux que l'IA me demande mon avis avant de changer de comportement, pour garder le contrôle.
#### Acceptance Criteria
1. WHEN un pattern est détecté THEN la GUI SHALL afficher un popup "Est-ce que je peux essayer ?"
2. WHEN un popup est affiché THEN l'application SHALL continuer à fonctionner (non-bloquant)
3. WHEN 10 secondes passent sans réponse THEN le popup SHALL se fermer automatiquement
4. WHEN l'utilisateur clique "Oui" THEN le système SHALL basculer en mode Suggestions
5. WHEN l'utilisateur clique "Non" THEN le système SHALL rester en mode Shadow
### Requirement 5: Indicateurs de Statut
**User Story:** En tant qu'utilisateur, je veux voir l'état actuel de l'IA en un coup d'œil, pour savoir ce qu'elle fait.
#### Acceptance Criteria
1. WHEN la GUI est affichée THEN elle SHALL montrer le mode actuel avec icône (👀/💡/🤖/⚡)
2. WHEN des actions sont observées THEN la GUI SHALL afficher le compteur d'actions
3. WHEN le fine-tuning est en cours THEN la GUI SHALL afficher "🧠 Apprentissage en cours..."
4. WHEN le fine-tuning est terminé THEN la GUI SHALL afficher "✅ Modèle amélioré"
5. WHEN aucune activité THEN la GUI SHALL afficher "💤 En attente..."
### Requirement 6: Logs Techniques pour Debugging
**User Story:** En tant que développeur, je veux des logs détaillés dans un fichier, pour pouvoir debugger les problèmes.
#### Acceptance Criteria
1. WHEN l'application tourne THEN le système SHALL écrire les logs techniques dans `geniusia2/logs/debug.log`
2. WHEN un événement survient THEN le log SHALL inclure timestamp, niveau, composant et message
3. WHEN une erreur survient THEN le log SHALL inclure la stack trace complète
4. WHEN le fichier dépasse 10MB THEN le système SHALL créer un nouveau fichier avec rotation
5. WHEN les logs sont écrits THEN ils SHALL être flushés immédiatement pour éviter les pertes
### Requirement 7: Communication GUI-Orchestrator
**User Story:** En tant que système, je dois pouvoir envoyer des messages de l'Orchestrator vers la GUI, pour tenir l'utilisateur informé.
#### Acceptance Criteria
1. WHEN l'Orchestrator détecte un événement THEN il SHALL envoyer un message à la GUI via signal Qt
2. WHEN un message est envoyé THEN il SHALL inclure type, contenu et timestamp
3. WHEN la GUI reçoit un message THEN elle SHALL l'afficher dans les 100ms
4. WHEN un dialogue est nécessaire THEN l'Orchestrator SHALL déclencher un popup via la GUI
5. WHEN l'utilisateur répond THEN la GUI SHALL notifier l'Orchestrator via callback
### Requirement 8: Statistiques Visibles
**User Story:** En tant qu'utilisateur, je veux voir ce que l'IA a appris, pour comprendre sa progression.
#### Acceptance Criteria
1. WHEN la GUI est affichée THEN elle SHALL montrer le nombre d'actions observées aujourd'hui
2. WHEN des workflows sont détectés THEN la GUI SHALL afficher le nombre de workflows
3. WHEN le fine-tuning collecte des exemples THEN la GUI SHALL afficher "X exemples collectés"
4. WHEN le fine-tuning est déclenché THEN la GUI SHALL afficher une barre de progression
5. WHEN les stats sont affichées THEN elles SHALL se mettre à jour en temps réel
### Requirement 9: Compatibilité Ubuntu
**User Story:** En tant qu'utilisateur Ubuntu, je veux que l'interface fonctionne nativement, sans problèmes d'affichage.
#### Acceptance Criteria
1. WHEN l'application démarre sur Ubuntu THEN la GUI SHALL utiliser le thème système
2. WHEN l'icône system tray est créée THEN elle SHALL être visible dans la barre supérieure
3. WHEN des popups sont affichés THEN ils SHALL respecter le window manager Ubuntu
4. WHEN la fenêtre est redimensionnée THEN elle SHALL respecter les contraintes de taille
5. WHEN l'application se ferme THEN elle SHALL libérer proprement les ressources système
### Requirement 10: Messages Contextuels
**User Story:** En tant qu'utilisateur, je veux que les messages soient adaptés au contexte, pour mieux comprendre ce qui se passe.
#### Acceptance Criteria
1. WHEN un workflow est détecté pour la première fois THEN le message SHALL expliquer ce qu'est un workflow
2. WHEN le mode progressif propose de basculer THEN le message SHALL expliquer ce que ça change
3. WHEN une erreur survient THEN le message SHALL suggérer une action corrective
4. WHEN le fine-tuning démarre THEN le message SHALL expliquer pourquoi
5. WHEN l'utilisateur n'a pas d'activité depuis 5 min THEN la GUI SHALL afficher un message d'encouragement

159
.kiro/specs/gui-logs-improvement/tasks.md Normal file
View File

@@ -0,0 +1,159 @@
# Implementation Plan - Amélioration GUI et Logs
- [x] 1. Créer le composant HumanLogger
- Implémenter la classe HumanLogger avec méthodes de formatage
- Créer des méthodes pour chaque type de message (observation, pattern, workflow, mode, fine-tuning)
- Ajouter support pour emojis et messages contextuels
- _Requirements: 2.1, 2.2, 2.3, 2.4, 10.1, 10.2, 10.3, 10.4_
- [x] 1.1 Écrire des tests unitaires pour HumanLogger
- Tester le formatage des messages
- Vérifier les emojis corrects
- Tester les messages contextuels
- _Requirements: 2.1, 2.2, 2.3, 2.4_
- [x] 2. Créer le composant LogsPanel
- Implémenter le widget Qt pour affichage des logs
- Ajouter système de scroll avec limite à 30 messages
- Implémenter auto-scroll conditionnel (seulement si déjà en bas)
- Ajouter formatage avec timestamp et emoji
- _Requirements: 3.1, 3.2, 3.3, 3.4, 3.5_
- [ ]* 2.1 Écrire un test de propriété pour la limite de logs
- **Property 1: Log History Bounds**
- **Validates: Requirements 3.3**
- [ ]* 2.2 Écrire des tests unitaires pour LogsPanel
- Tester l'ajout de logs
- Tester le scroll automatique
- Tester la limite de 30 messages
- _Requirements: 3.1, 3.2, 3.3, 3.4, 3.5_
- [x] 3. Créer le composant InteractiveDialog
- Implémenter le dialogue Qt avec timeout de 10 secondes
- Ajouter callbacks pour réponses utilisateur (accept/reject)
- Implémenter fermeture automatique après timeout
- Rendre le dialogue non-bloquant
- _Requirements: 4.1, 4.2, 4.3, 4.4, 4.5_
- [ ]* 3.1 Écrire un test de propriété pour le timeout
- **Property 2: Timeout Consistency**
- **Validates: Requirements 4.3**
- [ ]* 3.2 Écrire des tests unitaires pour InteractiveDialog
- Tester le timeout automatique
- Tester les callbacks
- Tester le comportement non-bloquant
- _Requirements: 4.1, 4.2, 4.3, 4.4, 4.5_
- [x] 4. Créer les modèles de données
- Implémenter LogMessage dataclass
- Implémenter GUIState dataclass
- Ajouter méthodes de sérialisation si nécessaire
- _Requirements: 5.1, 5.2, 5.3, 5.4, 5.5, 8.1, 8.2, 8.3, 8.4, 8.5_
- [x] 5. Créer le système de signaux Qt
- Implémenter GUISignals avec pyqtSignal
- Ajouter signaux pour log_message, update_stats, show_dialog, mode_changed
- Documenter l'utilisation des signaux
- _Requirements: 7.1, 7.2, 7.3, 7.4, 7.5_
- [x] 6. Créer la nouvelle ImprovedGUI
- Implémenter la fenêtre principale (300x400px)
- Ajouter le panneau de statut avec mode et icône
- Intégrer LogsPanel dans la fenêtre
- Ajouter les boutons Pause/Arrêter
- _Requirements: 1.1, 5.1, 5.2, 5.3, 5.4, 5.5_
- [x] 7. Implémenter le System Tray
- Créer l'icône dans la barre des tâches Ubuntu
- Implémenter le menu contextuel (Afficher/Masquer/Quitter)
- Gérer la minimisation vers le tray
- Ajouter fallback si system tray non disponible
- _Requirements: 1.2, 1.3, 1.4, 1.5, 9.1, 9.2, 9.3_
- [ ]* 7.1 Tester le system tray sur Ubuntu
- Vérifier l'icône dans la barre supérieure
- Tester le menu contextuel
- Tester la minimisation
- _Requirements: 1.3, 1.4, 9.2_
- [ ] 8. Implémenter l'affichage des statistiques
- Ajouter widget pour afficher actions observées
- Ajouter widget pour patterns détectés
- Ajouter widget pour workflows appris
- Ajouter indicateur de fine-tuning avec progression
- Implémenter mise à jour en temps réel
- _Requirements: 8.1, 8.2, 8.3, 8.4, 8.5_
- [ ]* 8.1 Écrire un test de propriété pour l'affichage du mode
- **Property 3: Mode Display Consistency**
- **Validates: Requirements 5.1**
- [x] 9. Intégrer HumanLogger dans l'Orchestrator
- Ajouter instance de HumanLogger dans Orchestrator
- Remplacer les logs techniques par des messages humains pour la GUI
- Envoyer les messages via les signaux Qt
- Garder les logs techniques dans le fichier debug.log
- _Requirements: 2.1, 2.2, 2.3, 2.4, 7.1, 7.2, 7.3_
- [ ]* 9.1 Écrire un test de propriété pour l'ordre des messages
- **Property 4: Message Ordering**
- **Validates: Requirements 2.1, 2.2, 2.3, 2.4**
- [ ] 10. Connecter les dialogues interactifs
- Modifier Orchestrator pour déclencher des dialogues via signaux
- Implémenter callbacks pour réponses utilisateur
- Gérer le changement de mode basé sur les réponses
- _Requirements: 4.1, 4.4, 4.5, 7.4, 7.5, 10.2_
- [ ]* 10.1 Écrire un test de propriété pour les dialogues non-bloquants
- **Property 5: Non-blocking Dialogs**
- **Validates: Requirements 4.2**
- [ ] 11. Implémenter le système de logs techniques
- Créer le répertoire geniusia2/logs si nécessaire
- Implémenter l'écriture dans debug.log avec format structuré
- Ajouter rotation des logs à 10MB
- Implémenter flush immédiat pour éviter pertes
- Gérer les erreurs (disque plein, permissions)
- _Requirements: 6.1, 6.2, 6.3, 6.4, 6.5_
- [ ]* 11.1 Écrire des tests unitaires pour le système de logs
- Tester l'écriture dans le fichier
- Tester la rotation à 10MB
- Tester le flush immédiat
- Tester les fallbacks en cas d'erreur
- _Requirements: 6.1, 6.2, 6.3, 6.4, 6.5_
- [ ] 12. Implémenter les messages contextuels
- Ajouter logique pour détecter première fois (workflow, mode change)
- Créer messages explicatifs pour première utilisation
- Ajouter suggestions d'actions correctives pour erreurs
- Implémenter message d'encouragement après inactivité
- _Requirements: 10.1, 10.2, 10.3, 10.4, 10.5_
- [ ] 13. Tester la compatibilité Ubuntu
- Vérifier le thème système
- Tester le system tray dans la barre supérieure
- Vérifier les popups avec le window manager
- Tester le redimensionnement de fenêtre
- Vérifier la libération des ressources à la fermeture
- _Requirements: 9.1, 9.2, 9.3, 9.4, 9.5_
- [ ] 14. Migration et intégration finale
- Renommer minimal_gui.py → minimal_gui_old.py
- Renommer improved_gui.py → minimal_gui.py
- Mettre à jour main.py pour utiliser la nouvelle GUI
- Supprimer les anciens boutons (liste blanche, etc.)
- Nettoyer le code inutilisé
- _Requirements: 1.1, 1.2, 1.3, 1.4, 1.5_
- [ ]* 14.1 Écrire des tests d'intégration
- Tester Orchestrator → GUI
- Tester Popup → Orchestrator
- Tester System Tray
- _Requirements: 7.1, 7.2, 7.3, 7.4, 7.5_
- [ ] 15. Checkpoint final - Vérifier que tout fonctionne
- Ensure all tests pass, ask the user if questions arise.

687
.kiro/specs/rpa-vision-v2/design.md Normal file
View File

@@ -0,0 +1,687 @@
# Document de Design
## Vue d'Ensemble
RPA Vision V2 est un système d'automatisation à apprentissage progressif construit sur une architecture cognitive qui suit le paradigme Observer → Réfléchir → Agir. Le système utilise des modèles de vision par ordinateur de pointe pour la détection d'éléments UI, des modèles de langage pour le raisonnement visuel, et des mécanismes de mémoire adaptative pour apprendre les flux de travail utilisateur de manière incrémentale à travers trois modes opérationnels : Shadow, Assisté et Autopilot.
L'architecture est modulaire, avec une séparation claire entre la logique centrale (orchestration, apprentissage, embeddings), les composants IA (détection vision, raisonnement LLM), l'interface utilisateur (GUI PyQt5), et la persistance des données (logs chiffrés, index FAISS, profils utilisateur).
## Architecture
### Architecture de Haut Niveau
```
┌─────────────────────────────────────────────────────────────────┐
│ Couche Interface Utilisateur │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────────────┐ │
│ │ GUI Minimale │ │ Dialogue de │ │ Tableau de Bord │ │
│ │ (PyQt5) │ │ Correction │ │ Résumé │ │
│ └──────────────┘ └──────────────┘ └──────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
↕
┌─────────────────────────────────────────────────────────────────┐
│ Couche Orchestration Centrale │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ Orchestrateur (Boucle Cognitive) │ │
│ │ Observer → Réfléchir → Agir → Apprendre → Répéter │ │
│ └──────────────────────────────────────────────────────────┘ │
│ ↕ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────────────┐ │
│ │ Gestionnaire │ │ Gestionnaire │ │ Rejeu Async │ │
│ │Apprentissage │ │ Embeddings │ │ │ │
│ └──────────────┘ └──────────────┘ └──────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
↕
┌─────────────────────────────────────────────────────────────────┐
│ Couche IA/Vision │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────────────┐ │
│ │ Utils Vision │ │ Gestionnaire │ │ Utils Image │ │
│ │ OWL-v2/DINO │ │ LLM │ │ Capture/ROI │ │
│ └──────────────┘ └──────────────┘ └──────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
↕
┌─────────────────────────────────────────────────────────────────┐
│ Couche Persistance des Données │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────────────┐ │
│ │ Logs │ │ Profils │ │ Index FAISS │ │
│ │ Chiffrés │ │ Utilisateur │ │ (Embeddings) │ │
│ └──────────────┘ └──────────────┘ └──────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
```
### Structure des Répertoires
```
/AI/amina/geniusia2/
├── core/
│ ├── orchestrator.py # Boucle cognitive principale
│ ├── replay_async.py # Moteur de rejeu d'actions
│ ├── embeddings_manager.py # Gestion OpenCLIP + FAISS
│ ├── learning_manager.py # État d'apprentissage & transitions de mode
│ ├── logger.py # Journalisation chiffrée AES-256
│ ├── config.py # Configuration globale
│ └── utils/
│ ├── image_utils.py # Capture d'écran, extraction ROI
│ ├── vision_utils.py # Interfaces modèles vision
│ └── input_utils.py # PyAutoGUI/PyDirectInput (AZERTY)
├── gui/
│ ├── minimal_gui.py # Interface PyQt5 principale
│ └── dialogs/
│ ├── correction_dialog.py
│ └── summary_dashboard.py
├── data/
│ ├── user_profiles/ # Profils d'apprentissage tâches (JSON)
│ ├── logs/ # Logs d'actions chiffrés
│ └── faiss_index/ # Index de mémoire visuelle
└── models/
├── openclip/ # Encodeurs visuels
├── owl_v2/ # Détecteur open-vocabulary
└── qwen2.5_vl/ # Modèle vision-langage (Ollama)
```
## Composants et Interfaces
### 1. Orchestrateur (orchestrator.py)
**Responsabilité** : Boucle cognitive principale implémentant le paradigme Observer → Réfléchir → Agir.
**Méthodes Clés** :
- `run()` : Boucle d'événements principale
- `capture_context()` : Capture d'écran et détection de fenêtre
- `detect_elements(frame, intent)` : Détection d'éléments UI basée sur la vision
- `reason_about_action(detections, context)` : Prise de décision basée sur LLM
- `execute_or_suggest(decision)` : Exécution d'action dépendante du mode
- `learn_from_feedback(feedback)` : Mise à jour de l'état d'apprentissage
**Interfaces** :
```python
class Orchestrator:
def __init__(self, config, learning_manager, vision_utils, llm_manager, gui):
self.config = config
self.learning_manager = learning_manager
self.vision = vision_utils
self.llm = llm_manager
self.gui = gui
self.running = False
def run(self):
"""Boucle cognitive principale"""
while self.running:
# Observer
frame = self.capture_context()
intent = self.learning_manager.get_current_intent()
# Réfléchir
detections = self.vision.detect(frame, intent)
decision = self.llm.reason_about_action(detections, context)
# Agir (dépendant du mode)
mode = self.learning_manager.get_mode()
if mode == "shadow":
self.learning_manager.observe(decision)
elif mode == "assist":
feedback = self.gui.show_suggestion(decision)
self.learning_manager.confirm_action(feedback)
elif mode == "auto":
self.execute_action(decision)
self.learning_manager.record_execution(decision)
```
### 2. Gestionnaire d'Apprentissage (learning_manager.py)
**Responsabilité** : Suit la progression d'apprentissage, gère les transitions de mode, calcule les scores de confiance.
**Attributs Clés** :
- `mode` : Mode opérationnel actuel (shadow/assist/auto)
- `tasks` : Dictionnaire des Séquence_Actions apprises
- `current_context` : Contexte de tâche actif
- `embeddings_index` : Référence à l'index FAISS
- `logger` : Référence au logger chiffré
**Méthodes Clés** :
- `observe(action)` : Enregistrer l'observation en mode Shadow
- `suggest_action(context)` : Générer une suggestion en mode Assisté
- `confirm_action(feedback)` : Traiter la validation/correction utilisateur
- `evaluate_task(task_id)` : Calculer confiance et concordance
- `should_transition_to_auto(task_id)` : Vérifier l'éligibilité autopilot
- `rollback_if_low_confidence(task_id)` : Rétrograder au mode Assisté
- `calculate_confidence(vision_conf, llm_score, history)` : Calculer le score de confiance
**Interfaces** :
```python
class LearningManager:
def __init__(self, embeddings_manager, logger, config):
self.mode = "shadow" # Mode initial
self.tasks = {} # task_id -> TaskProfile
self.embeddings_manager = embeddings_manager
self.logger = logger
self.config = config
def calculate_confidence(self, vision_conf, llm_score, task_id):
"""Calculer le score de confiance pondéré"""
history_score = self.tasks[task_id].get_historical_performance()
return 0.6 * vision_conf + 0.3 * llm_score + 0.1 * history_score
def should_transition_to_auto(self, task_id):
"""Vérifier si la tâche remplit les critères autopilot"""
task = self.tasks[task_id]
return (task.observation_count >= 20 and
task.concordance_rate >= 0.95)
def rollback_if_low_confidence(self, task_id):
"""Rétrograder au mode Assisté si confiance faible"""
task = self.tasks[task_id]
if task.mode == "auto" and task.confidence_score < 0.90:
task.mode = "assist"
self.logger.log_mode_transition(task_id, "auto", "assist", "low_confidence")
```
### 3. Gestionnaire d'Embeddings (embeddings_manager.py)
**Responsabilité** : Gère les embeddings visuels en utilisant OpenCLIP et l'indexation FAISS pour la recherche de similarité.
**Méthodes Clés** :
- `encode_image(image)` : Générer un embedding 512-d avec OpenCLIP
- `add_to_index(embedding, metadata)` : Stocker l'embedding dans FAISS
- `search_similar(embedding, k=5)` : Trouver les k embeddings les plus similaires
- `rebuild_index()` : Reconstruire l'index FAISS après mises à jour
- `get_embedding_similarity(emb1, emb2)` : Calculer la similarité cosinus
**Interfaces** :
```python
class EmbeddingsManager:
def __init__(self, model_path, index_path):
self.clip_model = self.load_openclip(model_path)
self.faiss_index = self.load_or_create_index(index_path)
self.metadata_store = {} # id -> mapping métadonnées
def encode_image(self, image):
"""Générer un embedding 512-d"""
with torch.no_grad():
embedding = self.clip_model.encode_image(image)
return embedding.cpu().numpy()
def add_to_index(self, embedding, metadata):
"""Stocker l'embedding avec métadonnées"""
idx = self.faiss_index.ntotal
self.faiss_index.add(embedding.reshape(1, -1))
self.metadata_store[idx] = metadata
return idx
def search_similar(self, query_embedding, k=5):
"""Trouver les k plus proches voisins"""
distances, indices = self.faiss_index.search(
query_embedding.reshape(1, -1), k
)
results = [
{
"id": int(idx),
"distance": float(dist),
"metadata": self.metadata_store[int(idx)]
}
for dist, idx in zip(distances[0], indices[0])
]
return results
```
### 4. Utils Vision (vision_utils.py)
**Responsabilité** : Interface vers les modèles de vision (OWL-v2, Grounding DINO, YOLO-World) pour la détection d'éléments UI.
**Méthodes Clés** :
- `detect_with_owlv2(prompt, frame)` : Détection open-vocabulary avec OWL-v2
- `detect_with_dino(prompt, frame)` : Détection Grounding DINO
- `detect_with_yolo(prompt, frame)` : Détection YOLO-World
- `select_best_detection(detections, context)` : Choisir la détection la plus confiante
- `extract_roi(frame, bbox)` : Extraire la région d'intérêt
**Format de Sortie de Détection** :
```python
{
"label": "valider_button",
"confidence": 0.93,
"bbox": (x, y, w, h), # Coordonnées en pixels
"embedding": np.array([...]), # Embedding visuel 512-d
"model": "owl-v2"
}
```
### 5. Gestionnaire LLM (llm_manager.py)
**Responsabilité** : Interface vers Ollama pour le raisonnement visuel utilisant Qwen 2.5-VL ou CogVLM.
**Méthodes Clés** :
- `reason_about_detections(detections, context, intent)` : Sélectionner la meilleure action
- `generate_with_vision(prompt, images)` : Génération multi-modale
- `score_action_relevance(action, intent)` : Calculer la confiance LLM
**Interfaces** :
```python
class LLMManager:
def __init__(self, model_name="qwen2.5-vl:3b", ollama_host="localhost:11434"):
self.model_name = model_name
self.ollama_client = ollama.Client(host=ollama_host)
def reason_about_detections(self, detections, context, intent):
"""Utiliser VLM pour sélectionner la meilleure action"""
prompt = f"""Étant donné ces éléments UI et l'intention utilisateur '{intent}',
avec quel élément devrait-on interagir ?
Éléments : {[d['label'] for d in detections]}
Contexte : {context}
Répondre avec le label de l'élément et la confiance (0-1)."""
images = [d['roi_image'] for d in detections]
response = self.ollama_client.generate(
model=self.model_name,
prompt=prompt,
images=images
)
return self.parse_llm_response(response)
```
### 6. Logger (logger.py)
**Responsabilité** : Journalisation chiffrée AES-256 avec format JSON structuré.
**Méthodes Clés** :
- `log_action(action_data)` : Enregistrer l'action avec chiffrement
- `log_correction(correction_data)` : Enregistrer la correction utilisateur
- `log_mode_transition(task_id, from_mode, to_mode, reason)` : Enregistrer les changements de mode
- `get_logs(task_id=None, start_time=None, end_time=None)` : Interroger les logs
- `encrypt_entry(data)` : Chiffrement AES-256
- `decrypt_entry(encrypted_data)` : Déchiffrement AES-256
**Format d'Entrée de Log** :
```python
{
"timestamp": "2025-11-13T10:32:04.123Z",
"window": "Dolibarr - Facturation",
"action": "click",
"element": "valider_button",
"bbox": [450, 320, 120, 40],
"confidence": 0.97,
"mode": "auto",
"result": "success",
"task_id": "ouvrir_facture_001"
}
```
### 7. GUI Minimale (minimal_gui.py)
**Responsabilité** : Interface PyQt5 pour l'affichage des modes, suggestions et retours utilisateur.
**Composants Clés** :
- Indicateur de mode (👀 Shadow | 🤝 Assisté | 🤖 Auto)
- Contrôles Start/Stop/Pause
- Superposition de suggestion avec éléments UI surlignés
- Raccourcis clavier (Entrée/Échap/Alt+C/Ctrl+Pause)
- Système de notifications pour alertes et confirmations
**Interfaces** :
```python
class MinimalGUI(QMainWindow):
def __init__(self, orchestrator):
super().__init__()
self.orchestrator = orchestrator
self.init_ui()
self.setup_shortcuts()
def show_suggestion(self, decision):
"""Afficher la superposition de suggestion et attendre l'entrée utilisateur"""
overlay = SuggestionOverlay(decision)
overlay.show()
return overlay.wait_for_feedback() # Retourne : "accept", "reject", ou "correct"
def show_notification(self, message, notification_type="info"):
"""Afficher une notification non intrusive"""
notification = QNotification(message, notification_type)
notification.show()
def update_mode_indicator(self, mode):
"""Mettre à jour l'icône de mode dans l'UI"""
icons = {"shadow": "👀", "assist": "🤝", "auto": "🤖"}
self.mode_label.setText(f"{icons[mode]} {mode.capitalize()}")
```
### 8. Tableau de Bord Résumé (summary_dashboard.py)
**Responsabilité** : Afficher les statistiques de tâches, niveaux de confiance et historique d'exécution.
**Fonctionnalités Clés** :
- Tableau de métriques en temps réel
- Filtrage et recherche de tâches
- Visualisation des tendances de confiance
- Historique des corrections
- Fonctionnalité d'export
**Métriques du Tableau de Bord** :
```python
{
"task_id": "ouvrir_facture",
"task_name": "Ouvrir Facture",
"mode": "auto",
"confidence": 97.3,
"observation_count": 45,
"concordance_rate": 98.2,
"correction_count": 1,
"last_execution": "2025-11-12T15:32:04",
"avg_latency_ms": 320,
"success_rate": 98.9
}
```
## Modèles de Données
### TaskProfile
```python
@dataclass
class TaskProfile:
task_id: str
task_name: str
mode: str # "shadow", "assist", "auto"
observation_count: int
concordance_rate: float
confidence_score: float
correction_count: int
last_execution: datetime
window_whitelist: List[str]
action_sequence: List[Action]
embeddings: List[np.ndarray]
metadata: Dict[str, Any]
def to_json(self):
"""Sérialiser en JSON pour la persistance"""
return {
"task_id": self.task_id,
"task_name": self.task_name,
"mode": self.mode,
"observation_count": self.observation_count,
"concordance_rate": self.concordance_rate,
"confidence_score": self.confidence_score,
"correction_count": self.correction_count,
"last_execution": self.last_execution.isoformat(),
"window_whitelist": self.window_whitelist,
"action_sequence": [a.to_dict() for a in self.action_sequence],
"metadata": self.metadata
}
```
### Action
```python
@dataclass
class Action:
action_type: str # "click", "type", "scroll", "wait"
target_element: str
bbox: Tuple[int, int, int, int]
confidence: float
embedding: np.ndarray
timestamp: datetime
window_title: str
def to_dict(self):
return {
"action_type": self.action_type,
"target_element": self.target_element,
"bbox": list(self.bbox),
"confidence": self.confidence,
"timestamp": self.timestamp.isoformat(),
"window_title": self.window_title
}
```
### Detection
```python
@dataclass
class Detection:
label: str
confidence: float
bbox: Tuple[int, int, int, int]
embedding: np.ndarray
model_source: str # "owl-v2", "dino", "yolo"
roi_image: np.ndarray
```
## Gestion des Erreurs
### Échecs des Modèles de Vision
**Scénario** : Le modèle de vision ne parvient pas à détecter d'éléments UI.
**Gestion** :
1. Logger l'erreur avec contexte (fenêtre, capture d'écran)
2. Réessayer avec un modèle de vision alternatif (OWL-v2 → DINO → YOLO)
3. Si tous les modèles échouent, notifier l'utilisateur et mettre en pause l'automatisation
4. Demander une correction manuelle ou une ré-observation
### Échecs du Raisonnement LLM
**Scénario** : Service Ollama indisponible ou LLM retourne une réponse à faible confiance.
**Gestion** :
1. Revenir à la détection pure basée sur la vision (bbox avec confiance la plus élevée)
2. Réduire temporairement le poids du LLM dans le calcul de confiance
3. Logger l'opération en mode dégradé
4. Notifier l'utilisateur de la capacité de raisonnement réduite
### Violations de Seuil de Confiance
**Scénario** : Le score de confiance tombe en dessous du seuil pendant le mode Autopilot.
**Gestion** :
1. Geler immédiatement l'exécution de l'action
2. Faire passer la tâche en mode Assisté
3. Afficher une notification expliquant la baisse de confiance
4. Demander la validation utilisateur pour la prochaine action
5. Logger la transition de mode avec raison
### Violations de Liste Blanche
**Scénario** : Le système tente une action dans une fenêtre non présente dans la liste blanche.
**Gestion** :
1. Bloquer l'action immédiatement
2. Logger la violation de sécurité avec détails de la fenêtre
3. Afficher une alerte à l'utilisateur
4. Inviter l'utilisateur à ajouter la fenêtre à la liste blanche ou abandonner la tâche
### Échecs de Rollback
**Scénario** : L'opération de rollback ne peut pas restaurer l'état précédent.
**Gestion** :
1. Logger l'échec du rollback avec les actions tentées
2. Notifier l'utilisateur du rollback partiel
3. Fournir des instructions d'annulation manuelle
4. Mettre en pause l'automatisation jusqu'à confirmation de l'état par l'utilisateur
### Corruption de l'Index FAISS
**Scénario** : L'index FAISS devient corrompu ou inaccessible.
**Gestion** :
1. Tenter la reconstruction de l'index à partir des embeddings stockés
2. Si la reconstruction échoue, créer un nouvel index et marquer les tâches pour ré-observation
3. Notifier l'utilisateur de la perte de données et des tâches affectées
4. Continuer l'opération avec un contexte historique réduit
## Stratégie de Test
### Tests Unitaires
**Composants Centraux** :
- `LearningManager` : Tester le calcul de confiance, transitions de mode, évaluation de tâche
- `EmbeddingsManager` : Tester l'encodage, l'indexation, la recherche de similarité
- `Logger` : Tester le chiffrement/déchiffrement, l'interrogation des logs
- `Vision Utils` : Tester le parsing de détection, l'extraction ROI
- `LLM Manager` : Tester la génération de prompts, le parsing de réponses
**Framework de Test** : pytest avec fixtures pour données mock
### Tests d'Intégration
**Scénarios** :
1. **Transition Shadow → Assisté** : Vérifier que l'accumulation d'observations déclenche le changement de mode
2. **Transition Assisté → Autopilot** : Vérifier les exigences de seuil de confiance et de compteur d'observations
3. **Rollback Autopilot → Assisté** : Vérifier que la faible confiance déclenche la rétrogradation
4. **Boucle de Retour de Correction** : Vérifier que les corrections mettent à jour les embeddings et améliorent les prédictions futures
5. **Application de Liste Blanche** : Vérifier que les actions sont bloquées dans les fenêtres non présentes dans la liste blanche
6. **Opération de Rollback** : Vérifier que les 3 dernières actions peuvent être inversées
### Tests de Bout en Bout
**Flux de Travail de Test** :
1. **Cycle d'Apprentissage Complet** : Observation Shadow → Validation Assistée → Exécution Autopilot
2. **Adaptation au Changement d'UI** : Introduire des changements d'UI et vérifier que le système détecte et s'adapte
3. **Gestion Multi-Tâches** : Apprendre et exécuter plusieurs tâches simultanément
4. **Conformité Sécurité** : Vérifier que tous les logs sont chiffrés, liste blanche appliquée, rollback fonctionnel
**Environnement de Test** : Application UI contrôlée (ex : application web de test avec éléments connus)
### Tests de Performance
**Métriques** :
- Latence observation-vers-suggestion (cible : <400ms)
- Temps d'inférence du modèle de vision
- Temps de raisonnement LLM
- Temps de recherche de similarité FAISS
- Surcharge de chiffrement des logs
**Outils** : pytest-benchmark, cProfile pour le profilage
### Tests d'Acceptation Utilisateur
**Scénarios** :
1. Utilisateur non technique apprend une tâche simple (ex : remplissage de formulaire)
2. Utilisateur avancé automatise un flux de travail complexe (ex : saisie de données multi-étapes)
3. Administrateur examine les logs et le tableau de bord
4. Utilisateur corrige les mauvaises détections et vérifie l'amélioration de l'apprentissage
**Critères de Succès** :
- Taux de concordance ≥95% après 20 observations
- Taux de correction <3% en mode Autopilot
- Satisfaction utilisateur avec la réactivité et la clarté de l'UI
## Considérations de Sécurité
### Chiffrement
- Tous les logs chiffrés avec AES-256-CBC
- Clés de chiffrement stockées dans un trousseau sécurisé (keychain système)
- Politique de rotation des clés : tous les 90 jours
### Contrôle d'Accès
- Liste blanche appliquée au niveau de l'orchestrateur
- Aucune action permise en dehors des fenêtres de la liste blanche
- Modifications de la liste blanche nécessitent une confirmation administrateur
### Piste d'Audit
- Toutes les actions loggées avec contexte complet
- Logs immuables (ajout uniquement)
- Intégrité des logs vérifiée avec signatures HMAC
### Confidentialité
- Captures d'écran stockées temporairement en mémoire uniquement
- Embeddings anonymisés (pas de PII dans les métadonnées)
- Profils utilisateur stockés localement, jamais transmis
### Mécanismes de Sécurité
- Arrêt d'urgence Ctrl+Pause (niveau interruption matérielle)
- Capacité de rollback pour les 3 dernières actions
- Rétrogradation automatique de mode en cas de perte de confiance
- Override manuel toujours disponible
## Optimisation des Performances
### Optimisation des Modèles de Vision
- Quantification des modèles (FP16 ou INT8) pour inférence plus rapide
- Traitement par lots de multiples détections
- Détection basée sur ROI pour réduire la zone de traitement
- Mise en cache des modèles pour éviter les chargements répétés
### Optimisation FAISS
- Utiliser l'index IVF (Inverted File) pour les grands ensembles d'embeddings
- Optimisation et compactage périodiques de l'index
- Accélération GPU pour la recherche de similarité (si disponible)
### Optimisation LLM
- Utiliser des modèles quantifiés plus petits (Qwen 3B paramètres)
- Mise en cache des prompts pour requêtes répétées
- Regroupement de multiples requêtes de raisonnement
- Déploiement Ollama local pour minimiser la latence
### Optimisation GUI
- Mises à jour UI non bloquantes utilisant signaux/slots Qt
- Chargement paresseux des données du tableau de bord
- Rendu efficace de superposition avec capture d'écran minimale
- Gestion d'entrée utilisateur avec anti-rebond
## Considérations de Déploiement
### Exigences Système
- OS : Linux (Ubuntu 20.04+), Windows 10+, macOS 11+
- RAM : 16GB minimum (32GB recommandé pour grands modèles)
- GPU : GPU NVIDIA avec 8GB+ VRAM (optionnel mais recommandé)
- Stockage : 20GB pour modèles et données
- Python : 3.9+
### Dépendances
- PyTorch 2.0+
- Transformers (Hugging Face)
- OpenCLIP
- FAISS (variante CPU ou GPU)
- Ollama (pour LLM local)
- PyQt5
- PyAutoGUI / PyDirectInput
- cryptography (pour chiffrement AES)
### Étapes d'Installation
1. Installer Ollama et télécharger le modèle Qwen 2.5-VL
2. Télécharger les modèles de vision (OWL-v2, Grounding DINO)
3. Installer les dépendances Python via requirements.txt
4. Initialiser l'index FAISS et les clés de chiffrement
5. Configurer la liste blanche et les paramètres initiaux
6. Lancer la GUI et commencer l'observation en mode Shadow
### Configuration
Configuration globale dans `core/config.py` :
```python
CONFIG = {
"models": {
"vision": "owl-v2", # ou "dino", "yolo"
"llm": "qwen2.5-vl:3b",
"clip": "ViT-B-32"
},
"thresholds": {
"autopilot_observations": 20,
"autopilot_concordance": 0.95,
"confidence_min": 0.90,
"rollback_confidence": 0.85
},
"performance": {
"max_latency_ms": 400,
"max_correction_rate": 0.03
},
"security": {
"encryption_algorithm": "AES-256-CBC",
"log_retention_days": 90,
"key_rotation_days": 90
}
}
```

156
.kiro/specs/rpa-vision-v2/requirements.md Normal file
View File

@@ -0,0 +1,156 @@
# Document d'Exigences
## Introduction
RPA Vision V2 est un système d'automatisation robotique à apprentissage progressif qui utilise la vision par ordinateur et l'IA pour observer, apprendre et automatiser les interactions avec les interfaces utilisateur. Le système évolue à travers trois modes opérationnels : Shadow (observation uniquement), Assisté (suggestion avec validation), et Autopilot (exécution autonome). Il exploite des modèles d'IA de vision (OWL-v2, Grounding DINO, YOLO-World), de raisonnement visuel (Qwen 2.5-VL), et de mémoire adaptative (embeddings OpenCLIP avec indexation FAISS) pour apprendre progressivement les flux de travail utilisateur tout en maintenant la sécurité, la traçabilité et le contrôle utilisateur.
## Glossaire
- **Système_RPA**: L'application complète RPA Vision V2 incluant tous les modules, modèles IA et interfaces utilisateur
- **Mode_Shadow**: Mode opérationnel où le Système_RPA observe les actions utilisateur sans exécuter d'actions automatisées
- **Mode_Assisté**: Mode opérationnel où le Système_RPA suggère des actions nécessitant une validation utilisateur explicite avant exécution
- **Mode_Autopilot**: Mode opérationnel où le Système_RPA exécute des actions de manière autonome après avoir atteint les seuils de confiance
- **Détecteur_Vision**: Composant IA utilisant OWL-v2, Grounding DINO ou YOLO-World pour la détection d'éléments UI
- **Raisonneur_Visuel**: Composant IA utilisant Qwen 2.5-VL ou CogVLM via Ollama pour la compréhension visuelle et la prise de décision
- **Gestionnaire_Embeddings**: Composant gérant les embeddings OpenCLIP et l'index FAISS pour la mémoire visuelle
- **Gestionnaire_Apprentissage**: Composant central suivant la progression d'apprentissage, les scores de confiance et les transitions de mode
- **Séquence_Actions**: Une série d'interactions UI effectuées par l'utilisateur que le Système_RPA apprend à répliquer
- **Score_Confiance**: Métrique calculée (0-100%) combinant détection vision, raisonnement LLM et performance historique de la tâche
- **Compteur_Observations**: Nombre de fois où le Système_RPA a observé une Séquence_Actions spécifique
- **Taux_Concordance**: Pourcentage de prédictions réussies correspondant aux actions utilisateur réelles sur les exécutions récentes
- **Liste_Blanche**: Liste des fenêtres d'application autorisées où le Système_RPA est autorisé à opérer
- **Journal_Chiffré**: Journal chiffré AES-256 enregistrant toutes les actions système, décisions et retours utilisateur
- **Événement_Correction**: Retour utilisateur indiquant que le Système_RPA a fait une prédiction ou action incorrecte
- **Opération_Rollback**: Annulation des trois dernières actions automatisées pour restaurer l'état précédent
- **Tableau_Bord**: Interface utilisateur affichant les statistiques de tâches, niveaux de confiance, corrections et historique d'exécution
- **Élément_UI**: Composant visuel à l'écran (bouton, champ, menu) que le Système_RPA peut détecter et avec lequel interagir
## Exigences
### Exigence 1
**User Story:** En tant qu'utilisateur titulaire, je veux que le système observe mes activités quotidiennes sans effectuer d'actions automatisées, afin qu'il puisse apprendre mes habitudes et séquences d'actions en toute sécurité.
#### Critères d'Acceptation
1. LORSQUE le Système_RPA fonctionne en Mode_Shadow, LE Système_RPA DOIT capturer toutes les trames d'écran et coordonnées d'Élément_UI sans exécuter d'actions automatisées.
2. TANT QUE le Système_RPA fonctionne en Mode_Shadow, LE Système_RPA DOIT enregistrer toutes les interactions utilisateur avec horodatages, titres de fenêtres et positions d'Élément_UI dans le Journal_Chiffré.
3. LE Système_RPA DOIT fournir une interface de journal accessible à l'utilisateur affichant toutes les observations capturées avec horodatages et métadonnées associées.
4. LORSQU'une interaction utilisateur est capturée en Mode_Shadow, LE Système_RPA DOIT générer et stocker des embeddings visuels via le Gestionnaire_Embeddings pour la reconnaissance de motifs future.
5. LE Système_RPA DOIT afficher un indicateur visuel montrant que le Mode_Shadow est actif (icône 👀) dans l'interface utilisateur.
### Exigence 2
**User Story:** En tant qu'utilisateur, je veux recevoir des suggestions d'actions avec un retour visuel clair et des contrôles de validation simples, afin de gagner du temps tout en gardant le contrôle total sur ce qui est exécuté.
#### Critères d'Acceptation
1. LORSQUE le Système_RPA fonctionne en Mode_Assisté, LE Système_RPA DOIT surligner les Élément_UI suggérés avec une superposition visuelle claire avant toute exécution d'action.
2. LORSQUE le Système_RPA présente une suggestion en Mode_Assisté, LE Système_RPA DOIT attendre une entrée utilisateur explicite (touche Entrée pour validation, touche Échap pour refus, ou Alt+C pour correction) avant de procéder.
3. LORSQU'un utilisateur appuie sur la touche Entrée sur une suggestion, LE Système_RPA DOIT exécuter l'action suggérée et enregistrer la validation dans le Journal_Chiffré.
4. LORSQU'un utilisateur appuie sur la touche Échap sur une suggestion, LE Système_RPA DOIT annuler l'action suggérée et enregistrer le refus dans le Journal_Chiffré.
5. LORSQU'un utilisateur appuie sur Alt+C sur une suggestion, LE Système_RPA DOIT ouvrir un dialogue de correction permettant à l'utilisateur de spécifier l'Élément_UI ou l'action correcte.
6. LORSQU'un Événement_Correction est enregistré, LE Gestionnaire_Apprentissage DOIT mettre à jour les embeddings visuels et les seuils de détection pour améliorer les prédictions futures.
7. LE Système_RPA DOIT afficher un indicateur visuel montrant que le Mode_Assisté est actif (icône 🤝) dans l'interface utilisateur.
### Exigence 3
**User Story:** En tant qu'utilisateur avancé, je veux que le système agisse automatiquement sur les séquences stables et répétitives, afin de pouvoir automatiser complètement les flux de travail que j'effectue régulièrement.
#### Critères d'Acceptation
1. LORSQU'une Séquence_Actions a un Compteur_Observations supérieur ou égal à 20 ET un Taux_Concordance supérieur ou égal à 95%, LE Système_RPA DOIT proposer la transition de cette Séquence_Actions vers le Mode_Autopilot.
2. LORSQUE le Système_RPA fonctionne en Mode_Autopilot pour une Séquence_Actions, LE Système_RPA DOIT exécuter les actions de manière autonome sans nécessiter de validation utilisateur.
3. LORSQU'un utilisateur appuie sur Ctrl+Pause à tout moment, LE Système_RPA DOIT immédiatement arrêter toutes les actions automatisées et revenir au Mode_Assisté.
4. LORSQUE le Système_RPA termine une action en Mode_Autopilot, LE Système_RPA DOIT afficher une notification post-action avec indicateur de succès (✔️) ou d'échec (❌).
5. LORSQU'une notification post-action affiche un indicateur d'échec, LE Système_RPA DOIT permettre à l'utilisateur de fournir un retour correctif dans les 5 secondes.
6. LORSQU'un retour correctif est fourni après une action en Mode_Autopilot, LE Gestionnaire_Apprentissage DOIT enregistrer l'Événement_Correction et ajuster le Score_Confiance pour cette Séquence_Actions.
7. LE Système_RPA DOIT afficher un indicateur visuel montrant que le Mode_Autopilot est actif (icône 🤖) dans l'interface utilisateur.
### Exigence 4
**User Story:** En tant que système, je veux apprendre et ajuster continuellement mes prédictions en fonction des résultats réels, afin de maintenir la fiabilité même lorsque les interfaces utilisateur changent.
#### Critères d'Acceptation
1. LORSQU'une action automatisée est exécutée, LE Gestionnaire_Apprentissage DOIT calculer le delta entre l'emplacement prédit de l'Élément_UI et l'emplacement réel confirmé par l'utilisateur.
2. LORSQUE le delta entre prédiction et emplacement réel dépasse 10 pixels, LE Gestionnaire_Apprentissage DOIT déclencher un cycle de ré-entraînement pour les embeddings visuels associés à cette Séquence_Actions.
3. LORSQU'un cycle de ré-entraînement est déclenché, LE Gestionnaire_Embeddings DOIT mettre à jour les embeddings OpenCLIP et reconstruire l'index FAISS avec les nouvelles données visuelles.
4. LORSQUE le Score_Confiance pour une Séquence_Actions en Mode_Autopilot tombe en dessous de 90%, LE Système_RPA DOIT automatiquement faire revenir cette Séquence_Actions au Mode_Assisté.
5. LORSQU'une Séquence_Actions passe du Mode_Autopilot au Mode_Assisté en raison d'une faible confiance, LE Système_RPA DOIT notifier l'utilisateur avec la raison de la transition.
6. LE Gestionnaire_Apprentissage DOIT recalculer le Score_Confiance après chaque exécution d'action en utilisant la formule : 0,6 × confiance_vision + 0,3 × score_llm + 0,1 × performance_historique_tâche.
### Exigence 5
**User Story:** En tant que superviseur ou administrateur, je veux garantir la sécurité et la traçabilité de toutes les actions système, afin de prévenir les comportements indésirables et maintenir la conformité d'audit.
#### Critères d'Acceptation
1. LE Système_RPA DOIT chiffrer toutes les entrées de journal en utilisant le chiffrement AES-256 avant d'écrire dans le Journal_Chiffré.
2. LE Système_RPA DOIT enregistrer chaque action avec horodatage, titre de fenêtre, type d'action, identifiant d'Élément_UI, Score_Confiance, mode opérationnel et résultat d'exécution dans le Journal_Chiffré.
3. LE Système_RPA DOIT appliquer une Liste_Blanche de fenêtres d'application autorisées et NE DOIT PAS exécuter d'actions dans les fenêtres absentes de la Liste_Blanche.
4. LORSQU'une action est tentée dans une fenêtre non présente dans la liste blanche, LE Système_RPA DOIT bloquer l'action et enregistrer un événement de violation de sécurité dans le Journal_Chiffré.
5. LE Système_RPA DOIT fournir une capacité d'Opération_Rollback permettant l'annulation des trois dernières actions automatisées.
6. LORSQU'une Opération_Rollback est initiée, LE Système_RPA DOIT restaurer l'état précédent en exécutant les actions inverses dans l'ordre chronologique inverse.
7. LE Tableau_Bord DOIT afficher le taux de succès, la latence moyenne, le nombre de corrections et l'horodatage de dernière exécution pour chaque Séquence_Actions apprise.
8. LE Tableau_Bord DOIT mettre à jour les métriques en temps réel au fur et à mesure que les actions sont exécutées et les retours reçus.
### Exigence 6
**User Story:** En tant que composant d'auto-surveillance du système, je veux détecter la dégradation des performances et alerter les utilisateurs, afin de prévenir la dérive comportementale après les mises à jour d'UI.
#### Critères d'Acceptation
1. LE Gestionnaire_Apprentissage DOIT maintenir des seuils de confiance dynamiques qui s'adaptent en fonction des tendances récentes du Taux_Concordance pour chaque Séquence_Actions.
2. LORSQUE le Score_Confiance pour une action en attente tombe en dessous du seuil dynamique, LE Système_RPA DOIT afficher une notification à l'utilisateur indiquant l'incertitude.
3. LORSQUE l'incertitude est détectée en Mode_Autopilot, LE Système_RPA DOIT geler l'exécution de cette Séquence_Actions jusqu'à ce qu'une validation utilisateur soit fournie.
4. LORSQUE le Taux_Concordance pour une Séquence_Actions tombe en dessous de 85% sur les 10 dernières exécutions, LE Système_RPA DOIT automatiquement faire passer cette Séquence_Actions au Mode_Assisté.
5. LORSQU'un changement d'UI est détecté (similarité d'embedding visuel inférieure à 70% par rapport aux motifs stockés), LE Système_RPA DOIT alerter l'utilisateur et demander une ré-observation de la Séquence_Actions affectée.
6. LE Système_RPA DOIT suivre le taux d'Événement_Correction par Séquence_Actions et DOIT alerter l'utilisateur lorsque le taux de correction dépasse 5% sur 20 exécutions.
## Critères d'Acceptation Globaux
1. LE Système_RPA DOIT maintenir un Taux_Concordance supérieur ou égal à 95% sur les 10 dernières actions pour toute Séquence_Actions en Mode_Autopilot.
2. LE Système_RPA DOIT exécuter zéro action dans les fenêtres absentes de la Liste_Blanche.
3. LE Système_RPA DOIT compléter le pipeline observation-vers-suggestion avec une latence inférieure à 400 millisecondes.
4. LE Système_RPA DOIT maintenir un taux d'Événement_Correction inférieur à 3% sur toutes les Séquence_Actions.
5. LE Tableau_Bord DOIT être accessible et afficher des métriques précises en temps réel à tout moment pendant l'opération du système.
6. LE Journal_Chiffré DOIT maintenir son intégrité sans perte de données ni corruption tout au long de l'opération du système.

222
.kiro/specs/rpa-vision-v2/tasks.md Normal file
View File

@@ -0,0 +1,222 @@
# Plan d'Implémentation
- [x] 1. Configurer la structure du projet et les dépendances
- Créer la structure de répertoires /AI/amina/geniusia2/ avec core/, gui/, data/, models/
- Créer requirements.txt avec PyTorch, Transformers, OpenCLIP, FAISS, PyQt5, cryptography, ollama
- Créer core/config.py avec configuration globale (modèles, seuils, performance, sécurité)
- Initialiser les répertoires data/ pour user_profiles/, logs/, faiss_index/
- _Exigences : 1.1, 1.2, 1.3, 1.4, 1.5, 2.1, 2.2, 2.3, 2.4, 2.5, 2.6, 2.7, 3.1, 3.2, 3.3, 3.4, 3.5, 3.6, 3.7, 4.1, 4.2, 4.3, 4.4, 4.5, 4.6, 5.1, 5.2, 5.3, 5.4, 5.5, 5.6, 5.7, 5.8, 6.1, 6.2, 6.3, 6.4, 6.5, 6.6_
- [x] 2. Implémenter les modèles de données et utilitaires de base
- [x] 2.1 Créer les dataclasses TaskProfile, Action, Detection dans core/models.py
- Implémenter TaskProfile avec sérialisation JSON
- Implémenter Action avec conversion dict
- Implémenter Detection avec métadonnées modèle
- _Exigences : 1.2, 1.4, 2.6, 4.1, 4.2, 4.3, 5.2, 6.1_
- [x] 2.2 Implémenter core/utils/image_utils.py pour capture d'écran et ROI
- Écrire fonction capture_screen() pour capturer l'écran complet
- Écrire fonction get_active_window() pour obtenir le titre de fenêtre active
- Écrire fonction extract_roi(frame, bbox) pour extraire région d'intérêt
- Écrire fonction draw_bbox(frame, bbox, label) pour dessiner bounding box
- _Exigences : 1.1, 1.2, 2.1, 4.1_
- [x] 3. Implémenter le système de journalisation chiffrée
- [x] 3.1 Créer core/logger.py avec chiffrement AES-256
- Implémenter classe Logger avec initialisation de clés AES
- Écrire méthode encrypt_entry(data) pour chiffrer les entrées
- Écrire méthode decrypt_entry(encrypted_data) pour déchiffrer
- Écrire méthode log_action(action_data) pour enregistrer actions
- Écrire méthode log_correction(correction_data) pour enregistrer corrections
- Écrire méthode log_mode_transition(task_id, from_mode, to_mode, reason)
- Écrire méthode get_logs(task_id, start_time, end_time) pour interroger logs
- _Exigences : 1.2, 1.3, 2.3, 2.4, 2.5, 2.6, 3.6, 4.1, 5.1, 5.2, 5.4, 6.2_
- [x] 4. Implémenter le gestionnaire d'embeddings avec OpenCLIP et FAISS
- [x] 4.1 Créer core/embeddings_manager.py
- Implémenter classe EmbeddingsManager avec chargement OpenCLIP
- Écrire méthode load_openclip(model_path) pour charger le modèle
- Écrire méthode load_or_create_index(index_path) pour FAISS
- Écrire méthode encode_image(image) pour générer embeddings 512-d
- Écrire méthode add_to_index(embedding, metadata) pour stocker
- Écrire méthode search_similar(query_embedding, k) pour recherche similarité
- Écrire méthode rebuild_index() pour reconstruire l'index
- Écrire méthode get_embedding_similarity(emb1, emb2) pour similarité cosinus
- _Exigences : 1.4, 2.6, 4.2, 4.3, 6.5_
- [x] 5. Implémenter les utilitaires de vision pour détection UI
- [x] 5.1 Créer core/utils/vision_utils.py avec interfaces modèles vision
- Implémenter classe VisionUtils avec chargement modèles (OWL-v2, DINO, YOLO)
- Écrire méthode detect_with_owlv2(prompt, frame) pour détection OWL-v2
- Écrire méthode detect_with_dino(prompt, frame) pour Grounding DINO
- Écrire méthode detect_with_yolo(prompt, frame) pour YOLO-World
- Écrire méthode select_best_detection(detections, context) pour sélection
- Implémenter gestion d'erreurs avec fallback entre modèles
- _Exigences : 1.1, 2.1, 4.1_
- [x] 6. Implémenter le gestionnaire LLM pour raisonnement visuel
- [x] 6.1 Créer core/llm_manager.py avec interface Ollama
- Implémenter classe LLMManager avec connexion Ollama
- Écrire méthode reason_about_detections(detections, context, intent)
- Écrire méthode generate_with_vision(prompt, images) pour génération multi-modale
- Écrire méthode score_action_relevance(action, intent) pour score confiance
- Écrire méthode parse_llm_response(response) pour parser réponses
- Implémenter gestion d'erreurs avec fallback vision pure
- _Exigences : 2.1, 4.6_
- [x] 7. Implémenter le gestionnaire d'apprentissage
- [x] 7.1 Créer core/learning_manager.py
- Implémenter classe LearningManager avec initialisation mode shadow
- Écrire méthode observe(action) pour enregistrer observations en mode Shadow
- Écrire méthode suggest_action(context) pour générer suggestions en mode Assisté
- Écrire méthode confirm_action(feedback) pour traiter validation/correction
- Écrire méthode calculate_confidence(vision_conf, llm_score, task_id) avec formule 0.6/0.3/0.1
- Écrire méthode evaluate_task(task_id) pour calculer concordance
- Écrire méthode should_transition_to_auto(task_id) pour vérifier critères (≥20 obs, ≥95% concordance)
- Écrire méthode rollback_if_low_confidence(task_id) pour rétrograder si <90%
- Écrire méthode get_current_intent() pour obtenir intention actuelle
- Écrire méthode record_execution(decision) pour enregistrer exécution
- Implémenter gestion des seuils dynamiques adaptatifs
- _Exigences : 1.2, 1.4, 2.6, 3.1, 3.6, 4.1, 4.2, 4.4, 4.5, 4.6, 6.1, 6.4, 6.6_
- [x] 8. Implémenter l'orchestrateur (boucle cognitive)
- [x] 8.1 Créer core/orchestrator.py
- Implémenter classe Orchestrator avec initialisation composants
- Écrire méthode run() pour boucle cognitive principale
- Écrire méthode capture_context() pour capture écran et fenêtre
- Écrire méthode detect_elements(frame, intent) pour détection UI
- Écrire méthode reason_about_action(detections, context) pour décision LLM
- Écrire méthode execute_or_suggest(decision) pour exécution selon mode
- Écrire méthode execute_action(decision) pour exécution réelle
- Écrire méthode learn_from_feedback(feedback) pour mise à jour apprentissage
- Implémenter vérification liste blanche avant exécution
- Implémenter gestion arrêt d'urgence Ctrl+Pause
- _Exigences : 1.1, 1.2, 2.1, 2.2, 2.3, 2.4, 2.5, 3.2, 3.3, 5.3, 5.4, 6.2, 6.3_
- [x] 9. Implémenter les utilitaires d'entrée pour actions UI
- [x] 9.1 Créer core/utils/input_utils.py
- Implémenter classe InputUtils avec support AZERTY
- Écrire méthode click(x, y) pour clic souris
- Écrire méthode type_text(text) pour saisie texte
- Écrire méthode scroll(direction, amount) pour défilement
- Écrire méthode wait(duration) pour attente
- Écrire méthode get_inverse_action(action) pour rollback
- _Exigences : 2.3, 3.2, 5.6_
- [x] 10. Implémenter le moteur de rejeu d'actions
- [x] 10.1 Créer core/replay_async.py
- Implémenter classe ReplayEngine pour rejeu asynchrone
- Écrire méthode replay_sequence(action_sequence) pour rejouer séquence
- Écrire méthode rollback_last_n(n) pour annuler n dernières actions
- Écrire méthode execute_inverse_actions(actions) pour rollback
- Implémenter gestion d'erreurs avec notification échec rollback
- _Exigences : 5.5, 5.6_
- [x] 11. Implémenter l'interface GUI minimale
- [x] 11.1 Créer gui/minimal_gui.py avec PyQt5
- Implémenter classe MinimalGUI héritant QMainWindow
- Créer interface avec indicateurs de mode (👀/🤝/🤖)
- Créer boutons Start/Stop/Pause
- Écrire méthode update_mode_indicator(mode) pour mise à jour icône
- Écrire méthode show_notification(message, type) pour notifications
- Implémenter setup_shortcuts() pour raccourcis clavier
- _Exigences : 1.5, 2.7, 3.7_
- [x] 11.2 Créer superposition de suggestion
- Implémenter classe SuggestionOverlay pour affichage suggestions
- Écrire méthode show_suggestion(decision) pour afficher avec surlignage
- Écrire méthode wait_for_feedback() pour attendre Entrée/Échap/Alt+C
- Implémenter surlignage visuel des éléments UI suggérés
- _Exigences : 2.1, 2.2, 2.3, 2.4, 2.5_
- [x] 12. Implémenter les dialogues de correction et notifications
- [x] 12.1 Créer gui/dialogs/correction_dialog.py
- Implémenter classe CorrectionDialog pour corrections utilisateur
- Créer interface permettant sélection élément correct
- Écrire méthode get_corrected_element() pour obtenir correction
- _Exigences : 2.5, 2.6_
- [x] 12.2 Implémenter système de notifications post-action
- Créer classe PostActionNotification pour succès/échec
- Implémenter affichage ✔️/❌ avec timeout 5 secondes
- Écrire méthode allow_corrective_feedback() pour retour correctif
- _Exigences : 3.4, 3.5, 3.6_
- [x] 12.3 Implémenter notifications de transition et alertes
- Créer notifications pour proposition passage Autopilot
- Créer notifications pour baisse confiance et retour Assisté
- Créer alertes pour violations liste blanche
- Créer alertes pour changements UI détectés
- _Exigences : 3.1, 4.5, 5.4, 6.2, 6.3, 6.5_
- [x] 13. Implémenter le tableau de bord résumé
- [x] 13.1 Créer gui/dialogs/summary_dashboard.py
- Implémenter classe SummaryDashboard avec QTableWidget
- Créer tableau avec colonnes : Tâche, Mode, Confiance, Observations, Concordance, Corrections, Dernière exécution
- Écrire méthode update_metrics(task_id, metrics) pour mise à jour temps réel
- Implémenter filtrage et recherche de tâches
- Implémenter visualisation tendances confiance
- Implémenter fonctionnalité export CSV/JSON
- _Exigences : 5.7, 5.8_
- [x] 14. Implémenter la gestion de la liste blanche
- [x] 14.1 Créer module de gestion liste blanche
- Implémenter classe WhitelistManager dans core/
- Écrire méthode is_window_allowed(window_title) pour vérification
- Écrire méthode add_to_whitelist(window_title) avec confirmation admin
- Écrire méthode load_whitelist() et save_whitelist() pour persistance
- Intégrer vérification dans orchestrator avant exécution
- _Exigences : 5.3, 5.4_
- [x] 15. Implémenter le système de détection de changements UI
- [x] 15.1 Créer module de détection de dérive
- Implémenter classe UIChangeDetector dans core/
- Écrire méthode detect_ui_change(current_embedding, stored_embeddings) avec seuil 70%
- Écrire méthode calculate_delta(predicted_bbox, actual_bbox) pour delta pixels
- Écrire méthode trigger_retraining(task_id) si delta >10 pixels
- Intégrer dans learning_manager pour surveillance continue
- _Exigences : 4.1, 4.2, 6.5_
- [x] 16. Implémenter le système de métriques et surveillance
- [x] 16.1 Créer module de métriques
- Implémenter classe MetricsCollector dans core/
- Écrire méthode track_latency(start_time, end_time) pour latence <400ms
- Écrire méthode track_concordance(task_id, success) pour taux concordance
- Écrire méthode track_correction_rate(task_id) pour taux <3%
- Écrire méthode check_performance_thresholds() pour alertes
- Intégrer dans orchestrator et learning_manager
- _Exigences : Critères globaux 1, 3, 4_
- [x] 17. Intégrer tous les composants et créer point d'entrée
- [x] 17.1 Créer main.py
- Initialiser configuration depuis config.py
- Instancier tous les gestionnaires (logger, embeddings, learning, vision, llm)
- Instancier orchestrator avec tous les composants
- Instancier GUI et connecter signaux/slots
- Lancer boucle cognitive dans thread séparé
- Lancer application PyQt5
- _Exigences : Toutes_
- [x] 17.2 Implémenter gestion gracieuse d'arrêt
- Écrire gestionnaire signal Ctrl+C pour arrêt propre
- Sauvegarder état apprentissage avant fermeture
- Fermer connexions (Ollama, FAISS)
- Finaliser logs
- _Exigences : 3.3, 5.1, 5.2_
- [x] 18. Créer scripts d'installation et configuration
- [x] 18.1 Créer setup.sh pour installation
- Script pour installer Ollama
- Script pour télécharger modèle Qwen 2.5-VL via Ollama
- Script pour télécharger modèles vision (OWL-v2, DINO)
- Script pour installer dépendances Python
- Script pour initialiser répertoires data/
- Script pour générer clés chiffrement initiales
- _Exigences : Toutes_
- [x] 18.2 Créer documentation utilisateur
- Rédiger README.md avec instructions installation
- Rédiger guide démarrage rapide
- Rédiger documentation configuration liste blanche
- Rédiger documentation raccourcis clavier
- _Exigences : Toutes_

981
.kiro/specs/ui-element-detection/design.md Normal file
View File

@@ -0,0 +1,981 @@
# Document de Design
## Vue d'Ensemble
Ce document décrit l'architecture et la conception détaillée du système de détection d'éléments d'UI et de fusion multi-modale pour GeniusIA v2. Le système transforme l'approche actuelle de comparaison plein écran en une plateforme RPA robuste capable de détecter et d'interagir avec des éléments d'interface individuels via une analyse vision multi-modale.
### Objectifs Principaux
1. Détecter et classifier les éléments d'UI individuels (boutons, champs, listes, etc.)
2. Créer des embeddings multi-modaux robustes combinant vision, texte et contexte
3. Permettre une correspondance de workflow au niveau élément plutôt qu'au niveau écran complet
4. Maintenir la compatibilité arrière avec le système existant
5. Implémenter progressivement sans casser les workflows existants
## Architecture
### Composants Principaux
```
┌─────────────────────────────────────────────────────────────┐
│ Orchestrator │
│ (Boucle Cognitive) │
└────────────────────┬────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ UIElementDetector (NOUVEAU) │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ Region │→ │ Character │→ │ Classifier │ │
│ │ Proposer │ │ -izer │ │ │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
└────────────────────┬────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ MultiModalEmbeddingManager (NOUVEAU) │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ Image │ │ Text │ │ Context │ │
│ │ Embedder │ │ Embedder │ │ Embedder │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ ┌──────────────┐ │
│ │ Fusion │ │
│ │ Engine │ │
│ └──────────────┘ │
└────────────────────┬────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ EnrichedScreenState (NOUVEAU) │
│ ┌──────────────────────────────────────────────────┐ │
│ │ ui_elements: List[UIElement] │ │
│ │ state_embedding: StateEmbedding │ │
│ │ perception: PerceptionData │ │
│ └──────────────────────────────────────────────────┘ │
└────────────────────┬────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ WorkflowMatcher (AMÉLIORÉ) │
│ - Matching au niveau élément │
│ - Matching au niveau état global │
│ - Mode legacy pour compatibilité │
└─────────────────────────────────────────────────────────────┘
```
### Flux de Données
1. **Capture d'écran** → Screenshot brut
2. **UIElementDetector** → Liste de UIElement
3. **MultiModalEmbeddingManager** → State embedding unifié
4. **EnrichedScreenState** → Structure complète avec éléments + embedding
5. **WorkflowMatcher** → Correspondance de workflow robuste
6. **Orchestrator** → Décision d'action basée sur éléments sémantiques
## Composants et Interfaces
### 1. UIElement (Structure de Données)
```python
@dataclass
class UIElement:
"""Représente un élément d'interface utilisateur détecté."""
# Identification
element_id: str # Hash stable: hash(app_name + center_bbox + label_normalized)
type: UIElementType # button, text_input, checkbox, tab, etc.
role: str # validate_invoice, search_field, primary_action, etc.
# Position
bbox: Tuple[int, int, int, int] # (x1, y1, x2, y2)
# Contenu
label: str # Texte visible de l'élément
# Embeddings visuels
visual: VisualData
# - screenshot_path: str
# - embedding_provider: str
# - embedding_vector_id: str
# Embeddings textuels
text: TextData
# - raw: str
# - normalized: str
# - embedding_provider: str
# - embedding_vector_id: str
# Propriétés
properties: ElementProperties
# - is_clickable: bool
# - is_focusable: bool
# - is_dangerous: bool
# Contexte
context: ElementContext
# - app_name: str
# - window_title: str
# - workflow_hint: Optional[str]
# Métadonnées
tags: List[str]
confidence: float # Score de confiance de la détection
```
### 2. EnrichedScreenState (Structure de Données)
```python
@dataclass
class EnrichedScreenState:
"""ScreenState enrichi avec éléments d'UI et embedding multi-modal."""
# Identification
screen_state_id: str
timestamp: datetime
session_id: str
# Fenêtre
window: WindowInfo
# - app_name: str
# - window_title: str
# - screen_resolution: Tuple[int, int]
# Données brutes
raw: RawData
# - screenshot_path: str
# Perception
perception: PerceptionData
# - detected_text: List[str]
# - ocr_results: Optional[Dict]
# Éléments d'UI (NOUVEAU)
ui_elements: List[UIElement]
# Embedding d'état unifié (NOUVEAU)
state_embedding: StateEmbedding
# - provider: str
# - vector_id: str
# - components: EmbeddingComponents
# - image_embedding: ComponentInfo
# - text_embedding: ComponentInfo
# - title_embedding: ComponentInfo
# - ui_embedding: ComponentInfo
# - context_embedding: ComponentInfo
# Contexte workflow
context: ContextData
# - current_workflow_candidate: Optional[str]
# - tags: List[str]
```
### 3. UIElementDetector (Nouveau Composant)
```python
class UIElementDetector:
"""Détecte et caractérise les éléments d'UI dans un screenshot."""
def __init__(
self,
vlm_model: VisionLanguageModel,
embedder: ImageEmbedder,
text_embedder: TextEmbedder,
config: DetectorConfig
):
self.vlm = vlm_model
self.image_embedder = embedder
self.text_embedder = text_embedder
self.config = config
# Composants du pipeline
self.region_proposer = RegionProposer(vlm_model, config)
self.characterizer = ElementCharacterizer(embedder, text_embedder)
self.classifier = ElementClassifier(config)
def detect_elements(
self,
screenshot: np.ndarray,
window_info: WindowInfo
) -> List[UIElement]:
"""
Pipeline complet de détection d'éléments.
Étapes:
1. Proposer des régions d'intérêt
2. Caractériser chaque région
3. Classifier type et rôle
"""
# Étape 1: Régions d'intérêt
regions = self.region_proposer.propose_regions(screenshot, window_info)
# Étape 2: Caractérisation
characterized = []
for region in regions:
char_element = self.characterizer.characterize(
screenshot, region, window_info
)
if char_element:
characterized.append(char_element)
# Étape 3: Classification
elements = []
for char_elem in characterized:
element = self.classifier.classify(char_elem, window_info)
elements.append(element)
return elements
```
### 4. RegionProposer (Sous-composant)
```python
class RegionProposer:
"""Propose des régions d'intérêt candidates pour les éléments d'UI."""
def propose_regions(
self,
screenshot: np.ndarray,
window_info: WindowInfo
) -> List[BoundingBox]:
"""
Propose des régions en combinant plusieurs méthodes:
- Détection de zones de texte
- Repérage de rectangles autour de texte
- Requête VLM pour zones cliquables (optionnel, coûteux)
"""
regions = []
# Méthode 1: Zones de texte (rapide)
if self.config.use_text_detection:
text_regions = self._detect_text_regions(screenshot)
regions.extend(text_regions)
# Méthode 2: Rectangles propres (heuristique)
if self.config.use_rectangle_detection:
rect_regions = self._detect_rectangles(screenshot)
regions.extend(rect_regions)
# Méthode 3: VLM (précis mais lent, à utiliser avec parcimonie)
if self.config.use_vlm_detection and self._should_use_vlm(window_info):
vlm_regions = self._query_vlm_for_regions(screenshot)
regions.extend(vlm_regions)
# Fusion et nettoyage
regions = self._merge_overlapping_regions(regions)
regions = self._filter_invalid_regions(regions)
return regions
def _should_use_vlm(self, window_info: WindowInfo) -> bool:
"""Décide si on doit utiliser le VLM (coûteux)."""
# Utiliser VLM seulement pour nouveaux écrans ou écrans importants
return (
self.config.vlm_on_new_screens and
self._is_new_screen(window_info)
)
```
### 5. MultiModalEmbeddingManager (Nouveau Composant)
```python
class MultiModalEmbeddingManager:
"""Gère la création d'embeddings multi-modaux pour les états d'écran."""
def __init__(
self,
image_embedder: ImageEmbedder,
text_embedder: TextEmbedder,
config: EmbeddingConfig
):
self.image_embedder = image_embedder
self.text_embedder = text_embedder
self.config = config
# Poids de fusion (configurables)
self.weights = {
'image': config.weight_image, # 0.5 par défaut
'text': config.weight_text, # 0.3 par défaut
'title': config.weight_title, # 0.1 par défaut
'ui': config.weight_ui, # 0.1 par défaut
'context': config.weight_context # 0.1 par défaut (à terme)
}
def create_state_embedding(
self,
screenshot: np.ndarray,
detected_text: List[str],
window_title: str,
ui_elements: List[UIElement],
context: Optional[Dict] = None
) -> StateEmbedding:
"""
Crée un embedding d'état unifié en fusionnant toutes les modalités.
"""
# Composante 1: Image globale
image_emb = self.image_embedder.embed(screenshot)
image_emb_norm = self._normalize(image_emb)
# Composante 2: Texte concaténé
text_concat = " ".join(detected_text)
text_emb = self.text_embedder.embed(text_concat)
text_emb_norm = self._normalize(text_emb)
# Composante 3: Titre de fenêtre
title_emb = self.text_embedder.embed(window_title)
title_emb_norm = self._normalize(title_emb)
# Composante 4: UI éléments (moyenne des embeddings importants)
ui_emb = self._compute_ui_embedding(ui_elements)
ui_emb_norm = self._normalize(ui_emb)
# Composante 5: Contexte (à implémenter plus tard)
context_emb = self._compute_context_embedding(context)
context_emb_norm = self._normalize(context_emb)
# Fusion pondérée
state_emb = (
self.weights['image'] * image_emb_norm +
self.weights['text'] * text_emb_norm +
self.weights['title'] * title_emb_norm +
self.weights['ui'] * ui_emb_norm +
self.weights['context'] * context_emb_norm
)
# Normalisation finale
state_emb_final = self._normalize(state_emb)
# Créer l'objet StateEmbedding avec composantes
return StateEmbedding(
provider="multimodal_fusion_v1",
vector=state_emb_final,
components={
'image': ComponentInfo(provider="openclip", vector=image_emb),
'text': ComponentInfo(provider="clip_text", vector=text_emb),
'title': ComponentInfo(provider="clip_text", vector=title_emb),
'ui': ComponentInfo(provider="openclip", vector=ui_emb),
'context': ComponentInfo(provider="numeric", vector=context_emb)
}
)
def _compute_ui_embedding(self, ui_elements: List[UIElement]) -> np.ndarray:
"""Calcule un embedding représentatif des éléments d'UI."""
if not ui_elements:
return np.zeros(self.config.embedding_dim)
# Filtrer les éléments importants (boutons primaires, etc.)
important_elements = [
elem for elem in ui_elements
if 'primary_action' in elem.tags or elem.properties.is_clickable
]
if not important_elements:
important_elements = ui_elements[:5] # Top 5 si aucun important
# Moyenne des embeddings
embeddings = [self._load_embedding(elem.visual.embedding_vector_id)
for elem in important_elements]
return np.mean(embeddings, axis=0)
```
### 6. WorkflowMatcher Amélioré
```python
class EnhancedWorkflowMatcher:
"""Matcher amélioré supportant correspondance au niveau élément."""
def __init__(
self,
legacy_matcher: WorkflowMatcher,
config: MatcherConfig
):
self.legacy_matcher = legacy_matcher
self.config = config
def match_workflow_step(
self,
current_state: EnrichedScreenState,
workflow: Workflow
) -> MatchResult:
"""
Trouve la meilleure correspondance de workflow.
Stratégie:
1. Si le workflow a des descripteurs d'éléments → matching élément
2. Sinon → matching legacy (plein écran)
"""
if self._has_element_descriptors(workflow):
return self._match_by_elements(current_state, workflow)
else:
return self._match_legacy(current_state, workflow)
def _match_by_elements(
self,
current_state: EnrichedScreenState,
workflow: Workflow
) -> MatchResult:
"""Matching basé sur les éléments d'UI."""
best_match = None
best_score = 0.0
for step in workflow.steps:
# Comparer state_embedding
state_sim = self._compare_state_embeddings(
current_state.state_embedding,
step.expected_state_embedding
)
# Comparer éléments requis
element_sim = self._compare_required_elements(
current_state.ui_elements,
step.required_elements
)
# Score combiné
score = (
self.config.weight_state * state_sim +
self.config.weight_elements * element_sim
)
if score > best_score:
best_score = score
best_match = step
return MatchResult(
matched_step=best_match,
confidence=best_score,
method="element_based"
)
def _compare_required_elements(
self,
detected: List[UIElement],
required: List[ElementDescriptor]
) -> float:
"""Compare les éléments détectés aux éléments requis."""
if not required:
return 1.0
matches = 0
for req_elem in required:
# Chercher un élément correspondant
for det_elem in detected:
if self._elements_match(det_elem, req_elem):
matches += 1
break
return matches / len(required)
def _elements_match(
self,
detected: UIElement,
required: ElementDescriptor
) -> bool:
"""Vérifie si un élément détecté correspond à un descripteur."""
# Vérifier type
if required.type and detected.type != required.type:
return False
# Vérifier rôle
if required.role and detected.role != required.role:
return False
# Vérifier similarité sémantique (embedding)
if required.embedding:
sim = cosine_similarity(
detected.text.embedding_vector,
required.embedding
)
if sim < self.config.min_semantic_similarity:
return False
# Vérifier position relative (optionnel)
if required.position_hint:
if not self._position_matches(detected.bbox, required.position_hint):
return False
return True
```
## Modèles de Données
### Formats JSON
#### UIElement JSON (v1)
```json
{
"schema_version": "uielement_v1",
"element_id": "el_btn_valider_001",
"type": "button",
"role": "validate_invoice",
"bbox": [1600, 900, 1800, 940],
"label": "Valider la facture",
"confidence": 0.95,
"detection_method": "heuristic_rectangle",
"visual": {
"screenshot_path": "data/screens/elements/el_btn_valider_001.png",
"embedding": {
"provider": "openclip_ViT-B-32",
"vector_id": "data/embeddings/elements/el_btn_valider_001.npy"
}
},
"text": {
"raw": "Valider la facture",
"normalized": "valider facture",
"embedding": {
"provider": "clip_text",
"vector_id": "data/embeddings/elements/el_btn_valider_001_text.npy"
}
},
"properties": {
"is_clickable": true,
"is_focusable": true,
"is_dangerous": false
},
"context": {
"app_name": "logiciel_facturation",
"window_title": "Facture n° 2025-00123 - DUPONT Jean",
"workflow_hint": "WF_validation_facture"
},
"tags": ["primary_action", "billing"]
}
```
**Notes importantes :**
- `schema_version` : Permet la compatibilité future et la migration de schémas
- `detection_method` : Trace comment l'élément a été détecté (heuristic_rectangle, vlm_query, manual, etc.)
- `embedding` : Peut être `null` en mode ultralight pour permettre une détection progressive
- `confidence` : Score de confiance de la détection (0.0 à 1.0)
#### EnrichedScreenState JSON (v1)
```json
{
"schema_version": "screenstate_v1",
"mode": "complete",
"screen_state_id": "screen_2025-11-21T10-15-32.123Z",
"timestamp": "2025-11-21T10:15:32.123Z",
"session_id": "session_abc123",
"environment": {
"platform": "windows",
"display_scale": 1.0
},
"window": {
"app_name": "logiciel_facturation",
"window_title": "Factures - Clinique Demo",
"screen_resolution": [1920, 1080]
},
"raw": {
"screenshot_path": "data/screens/2025-11-21/10-15-32_factures.png"
},
"perception": {
"detected_text": [
"Factures",
"Patient",
"Montant",
"Statut",
"À valider",
"Validée"
]
},
"ui_elements": [
{
"schema_version": "uielement_v1",
"element_id": "el_btn_valider",
"type": "button",
"role": "validate_invoice",
"bbox": [1600, 900, 1800, 940],
"label": "Valider la facture",
"confidence": 0.95
}
],
"state_embedding": {
"provider": "multimodal_fusion_v1",
"vector_id": "data/embeddings/screens/state/screen_2025-11-21T10-15-32.123Z.npy",
"components": {
"image_embedding": {
"provider": "openclip_ViT-B-32",
"vector_id": "data/embeddings/screens/image/screen_2025-11-21T10-15-32.123Z.npy"
},
"text_embedding": {
"provider": "clip_text",
"vector_id": "data/embeddings/screens/text/screen_2025-11-21T10-15-32.123Z.npy"
},
"title_embedding": {
"provider": "clip_text",
"vector_id": "data/embeddings/screens/title/screen_2025-11-21T10-15-32.123Z.npy"
},
"ui_embedding": {
"provider": "openclip_ViT-B-32",
"vector_id": "data/embeddings/screens/ui/screen_2025-11-21T10-15-32.123Z.npy"
},
"context_embedding": {
"provider": "numeric_context_v1",
"vector_id": "data/embeddings/screens/context/screen_2025-11-21T10-15-32.123Z.npy"
}
}
},
"context": {
"current_workflow_candidate": "WF_validation_facture",
"tags": ["facturation"]
},
"processing_metadata": {
"detection_time_ms": 1234,
"embedding_time_ms": 567,
"num_elements_detected": 1,
"vlm_used": false
}
}
```
**Notes importantes :**
- `schema_version` : Permet la compatibilité future et la migration de schémas
- `mode` : Indique le niveau de traitement ("light", "enriched", "complete")
- `environment` : Informations sur la plateforme et l'échelle d'affichage (crucial pour gérer les différences Windows/Linux/Mac et les DPI)
- `state_embedding.components` : Peut être `null` en mode light
- `processing_metadata` : Métriques de performance pour monitoring et optimisation (optionnel)
**Exemples de modes :**
Mode Light :
```json
{
"schema_version": "screenstate_v1",
"mode": "light",
"ui_elements": [],
"state_embedding": {
"provider": "openclip_ViT-B-32",
"vector_id": "data/embeddings/screens/image/screen_xxx.npy",
"components": null
}
}
```
Mode Enriched :
```json
{
"schema_version": "screenstate_v1",
"mode": "enriched",
"ui_elements": [/* éléments détectés */],
"state_embedding": {
"provider": "openclip_ViT-B-32",
"vector_id": "data/embeddings/screens/image/screen_xxx.npy",
"components": null
}
}
```
Mode Complete :
```json
{
"schema_version": "screenstate_v1",
"mode": "complete",
"ui_elements": [/* éléments détectés */],
"state_embedding": {
"provider": "multimodal_fusion_v1",
"vector_id": "data/embeddings/screens/state/screen_xxx.npy",
"components": {/* toutes les composantes */}
}
}
```
## Gestion des Erreurs
### Stratégies de Fallback
1. **Détection d'éléments échoue** → Continuer avec liste vide, utiliser matching legacy
2. **VLM indisponible** → Utiliser heuristiques simples uniquement
3. **Embedding échoue** → Utiliser embedding par défaut (zéros) avec flag d'avertissement
4. **Élément requis manquant** → Passer en mode assisté, demander aide utilisateur
### Logging et Debug
- Chaque étape du pipeline doit logger son état
- Les échecs de détection doivent être enregistrés avec screenshots
- Les scores de matching doivent être tracés pour analyse
- Mode debug avec visualisation des bounding boxes détectées
## Stratégie de Test
### Tests Unitaires
1. **RegionProposer**: Tester détection de zones sur images synthétiques
2. **ElementCharacterizer**: Vérifier extraction d'embeddings
3. **ElementClassifier**: Valider classification de types connus
4. **MultiModalEmbeddingManager**: Tester fusion avec poids variés
5. **EnhancedWorkflowMatcher**: Vérifier matching élément vs legacy
### Tests d'Intégration
1. **Pipeline complet**: Screenshot → UIElements → StateEmbedding
2. **Compatibilité**: Anciens workflows fonctionnent toujours
3. **Performance**: Temps de traitement < 2s par écran
4. **Robustesse**: Variations visuelles (thème, taille) ne cassent pas matching
### Tests de Propriétés (Property-Based Testing)
À définir dans la section Correctness Properties ci-dessous.
## Propriétés de Correction
*Une propriété est une caractéristique ou un comportement qui devrait être vrai pour toutes les exécutions valides d'un système - essentiellement, une déclaration formelle sur ce que le système devrait faire. Les propriétés servent de pont entre les spécifications lisibles par l'humain et les garanties de correction vérifiables par machine.*
### Propriété 1: Complétude de Détection d'Éléments
*Pour tout* screenshot contenant des éléments interactifs, le système doit détecter tous les éléments interactifs présents et générer un UIElement pour chacun avec tous les champs requis (element_id, type, role, bbox, label, visual, text, properties, context, tags).
**Valide: Exigences 1.1, 1.2, 1.3, 1.4, 1.5, 11.2**
### Propriété 2: Validité des Types d'Éléments
*Pour tout* UIElement détecté, le champ type doit être l'un des types valides suivants : button, text_input, dropdown, tab, checkbox, radio_button, link, ou generic_interactive.
**Valide: Exigences 2.1, 2.4**
### Propriété 3: Présence du Score de Confiance
*Pour tout* UIElement créé, un score de confiance entre 0.0 et 1.0 doit être assigné et stocké dans le descripteur.
**Valide: Exigences 2.3, 2.4**
### Propriété 4: Extraction de Description Sémantique
*Pour tout* UIElement analysé, une description sémantique non-vide doit être générée par le VLM et stockée dans le descripteur.
**Valide: Exigences 3.1, 3.2**
### Propriété 5: Unicité des Identifiants d'Éléments
*Pour tout* ensemble d'UIElement détectés dans un même screenshot, si deux éléments ont des positions ou labels différents, alors leurs element_id doivent être différents.
**Valide: Exigences 3.5, 11.1**
### Propriété 6: Stabilité des Identifiants
*Pour tout* UIElement créé deux fois avec les mêmes paramètres (app_name, centre_bbox, label_normalized), l'element_id généré doit être identique.
**Valide: Exigences 11.1**
### Propriété 7: Structure Complète du State Embedding
*Pour tout* state_embedding généré, il doit contenir toutes les composantes suivantes : image_embedding, text_embedding, title_embedding, ui_embedding, et context_embedding, chacune avec un provider et un vector_id valides.
**Valide: Exigences 4.1, 4.5, 12.3, 14.1**
### Propriété 8: Extraction de Texte Systématique
*Pour tout* screenshot traité, le système doit extraire le contenu textuel (liste potentiellement vide si aucun texte) et le stocker dans le champ perception.detected_text du ScreenState.
**Valide: Exigences 4.2, 7.1**
### Propriété 9: Présence du Titre de Fenêtre
*Pour tout* ScreenState créé, le champ window.window_title doit être présent et non-null.
**Valide: Exigences 4.3**
### Propriété 10: Inclusion du Contexte Workflow
*Pour tout* ScreenState où le contexte workflow est disponible, ce contexte doit être inclus dans le state_embedding et stocké dans le champ context.
**Valide: Exigences 4.4, 8.1**
### Propriété 11: Normalisation des Embeddings
*Pour tout* state_embedding final généré, la norme L2 du vecteur doit être égale à 1.0 (±0.001 pour tolérance numérique).
**Valide: Exigences 4.5, 14.4**
### Propriété 12: Dimension Fixe des Embeddings
*Pour tout* state_embedding généré, la dimension du vecteur doit être constante et égale à la dimension configurée (ex: 512).
**Valide: Exigences 5.1**
### Propriété 13: Robustesse aux Variations Visuelles Légères
*Pour tout* screenshot S et sa variation légère S' (changement de couleur, taille ±10%, position ±20px), la similarité cosinus entre state_embedding(S) et state_embedding(S') doit être ≥ 0.85.
**Valide: Exigences 5.3**
### Propriété 14: Discrimination Sémantique
*Pour tout* screenshot S1 et screenshot S2 sémantiquement différents (écrans différents, contenus différents), la similarité cosinus entre state_embedding(S1) et state_embedding(S2) doit être ≤ 0.70.
**Valide: Exigences 5.4**
### Propriété 15: Association des Empreintes
*Pour tout* state_embedding stocké, il doit être associé à au moins un workflow_step ou un ScreenState avec un screen_state_id valide.
**Valide: Exigences 5.5**
### Propriété 16: Vérification des Éléments Requis
*Pour tout* workflow avec N éléments requis, si le ScreenState actuel contient moins de N éléments correspondants, alors le score de matching doit être < 0.5 (échec).
**Valide: Exigences 6.3**
### Propriété 17: Bonus des Éléments Optionnels
*Pour tout* workflow avec des éléments optionnels, le score de matching avec tous les éléments optionnels présents doit être strictement supérieur au score sans les éléments optionnels.
**Valide: Exigences 6.4**
### Propriété 18: Feedback Détaillé sur Échec
*Pour tout* échec de matching de workflow, le système doit retourner un MatchResult contenant une liste non-vide de différences détectées (éléments manquants, types incorrects, etc.).
**Valide: Exigences 6.5**
### Propriété 19: Préservation des Informations Spatiales du Texte
*Pour tout* texte détecté dans un screenshot, des coordonnées spatiales (bbox ou position) doivent être stockées avec le texte.
**Valide: Exigences 7.2**
### Propriété 20: Association Texte-Élément
*Pour tout* UIElement contenant du texte visible, ce texte doit être présent dans le champ text.raw du descripteur d'élément.
**Valide: Exigences 7.3**
### Propriété 21: Cohérence du Texte Extrait
*Pour tout* texte extrait d'un screenshot, il doit apparaître à la fois dans perception.detected_text du ScreenState ET dans les descripteurs text.raw des UIElement correspondants.
**Valide: Exigences 7.5**
### Propriété 22: Sensibilité au Contexte
*Pour tout* ScreenState avec contexte C1 et ScreenState avec contexte C2 (où C1 ≠ C2), les state_embedding doivent différer (similarité cosinus < 0.95).
**Valide: Exigences 8.2**
### Propriété 23: Robustesse en Absence de Contexte
*Pour tout* screenshot sans contexte workflow disponible, le système doit quand même générer un state_embedding valide avec dimension correcte et norme unitaire.
**Valide: Exigences 8.4**
### Propriété 24: Capture du Contexte d'Enregistrement
*Pour tout* workflow_step stocké, si un contexte était présent pendant l'enregistrement, ce contexte doit être sauvegardé dans le champ context du step.
**Valide: Exigences 8.5**
### Propriété 25: Compatibilité Arrière des Workflows Legacy
*Pour tout* workflow existant créé avant l'implémentation du système d'éléments, le système doit continuer à le traiter avec le matcher legacy et produire un résultat de matching valide.
**Valide: Exigences 9.1, 9.2**
### Propriété 26: Routage Correct des Workflows
*Pour tout* workflow avec descripteurs d'éléments (has_element_descriptors = true), le système doit utiliser le matcher amélioré ; pour tout workflow sans descripteurs, le système doit utiliser le matcher legacy.
**Valide: Exigences 9.2, 9.3**
### Propriété 27: Performance de Détection
*Pour tout* screenshot typique (1920x1080, 5-20 éléments), le temps de détection d'éléments doit être ≤ 2 secondes.
**Valide: Exigences 10.1**
### Propriété 28: Performance de Génération d'Embedding
*Pour tout* state_embedding généré, le temps de calcul doit être ≤ 1 seconde.
**Valide: Exigences 10.2**
### Propriété 29: Performance de Comparaison
*Pour tout* appel à la fonction de comparaison de state_embedding, le temps d'exécution doit être ≤ 100ms.
**Valide: Exigences 10.3**
### Propriété 30: Efficacité du Cache VLM
*Pour tout* screenshot traité deux fois consécutivement, le temps de traitement de la deuxième extraction de texte VLM doit être ≤ 10% du temps de la première (cache hit).
**Valide: Exigences 10.4**
### Propriété 31: Scalabilité des Requêtes
*Pour tout* base de données d'éléments contenant N éléments (où N ≤ 100,000), le temps de requête pour trouver un élément par element_id doit être ≤ 50ms.
**Valide: Exigences 10.5**
### Propriété 32: Complétude de la Structure UIElement
*Pour tout* UIElement stocké, tous les champs suivants doivent être présents et non-null : element_id, type, role, bbox, label, visual (avec screenshot_path, provider, vector_id), text (avec raw, normalized, provider, vector_id), properties, context, tags.
**Valide: Exigences 11.2, 11.3, 11.4**
### Propriété 33: Round-Trip de Sérialisation UIElement
*Pour tout* UIElement sérialisé en JSON puis désérialisé, l'objet résultant doit être égal à l'objet original (tous les champs identiques).
**Valide: Exigences 11.5**
### Propriété 34: Complétude de la Structure ScreenState
*Pour tout* ScreenState créé, tous les champs suivants doivent être présents : screen_state_id, timestamp, session_id, window, raw, perception, ui_elements, state_embedding, context.
**Valide: Exigences 12.1**
### Propriété 35: Stockage des Éléments Détectés
*Pour tout* ScreenState où des UIElement ont été détectés, ces éléments doivent être présents dans le champ ui_elements (liste non-vide).
**Valide: Exigences 12.2**
### Propriété 36: Round-Trip de Sérialisation ScreenState
*Pour tout* ScreenState sérialisé en JSON puis désérialisé, tous les embeddings doivent pouvoir être reconstruits à partir des vector_id et être identiques aux embeddings originaux (distance L2 < 0.001).
**Valide: Exigences 12.4, 12.5**
### Propriété 37: Complétude de la Caractérisation
*Pour tout* élément caractérisé par le pipeline, les champs suivants doivent être extraits : crop image, embedding image, texte, embedding texte, bbox.
**Valide: Exigences 13.3**
### Propriété 38: Complétude de la Classification
*Pour tout* élément classifié, les champs type et role doivent être présents et non-vides.
**Valide: Exigences 13.4**
### Propriété 39: Robustesse du Pipeline
*Pour tout* screenshot contenant N éléments dont 1 élément problématique (causant une erreur), le pipeline doit quand même produire N-1 UIElement valides pour les autres éléments.
**Valide: Exigences 13.5**
### Propriété 40: Normalisation des Composantes
*Pour tout* state_embedding en cours de génération, chaque composante individuelle (image_embedding, text_embedding, title_embedding, ui_embedding, context_embedding) doit avoir une norme L2 = 1.0 avant fusion.
**Valide: Exigences 14.2**
### Propriété 41: Stockage des Composantes
*Pour tout* state_embedding généré, toutes les composantes individuelles doivent être stockées séparément avec leurs provider et vector_id respectifs.
**Valide: Exigences 14.5**
### Propriété 42: Compatibilité de Lecture Multi-Mode
*Pour tout* fichier de données créé en mode "light", "enrichi" ou "complet", le système doit pouvoir le lire quel que soit le mode actuel, sans erreur de parsing.
**Valide: Exigences 15.5**

199
.kiro/specs/ui-element-detection/requirements.md Normal file
View File

@@ -0,0 +1,199 @@
# Document d'Exigences
## Introduction
Cette spécification définit les exigences pour transformer GeniusIA v2 d'un système de comparaison plein écran en une plateforme RPA robuste capable de détecter et d'interagir avec des éléments d'interface individuels via une analyse vision multi-modale. Le système combinera les embeddings visuels (CLIP, Pix2Struct), l'extraction de texte VLM (Qwen3-VL), le contexte de fenêtre et les métadonnées de workflow dans une "empreinte d'état" unifiée permettant une automatisation d'interface précise et fiable.
## Glossaire
- **Élément d'UI**: Un composant interactif à l'écran tel qu'un bouton, champ de texte, liste déroulante, onglet, case à cocher ou lien
- **Capture Locale**: Une capture d'écran recadrée focalisée sur un élément d'UI spécifique plutôt que sur l'écran complet
- **VLM (Vision Language Model)**: Un modèle comme Qwen3-VL capable d'extraire du texte et de décrire du contenu visuel
- **Embedding d'État**: Une représentation vectorielle multi-modale combinant informations visuelles, textuelles et contextuelles sur un état d'écran
- **Élément Interactif**: Un composant d'UI pouvant recevoir une entrée utilisateur ou déclencher des actions
- **Descripteur d'Élément**: Une représentation structurée contenant (capture locale + embedding + description VLM + position)
- **Empreinte d'État Unifiée**: Un embedding complet combinant screenshot, texte détecté, titre de fenêtre et contexte workflow
- **Système GeniusIA**: Le système d'automatisation RPA en cours d'amélioration
- **Gestionnaire d'Embeddings**: Le composant responsable de la génération et gestion des embeddings
- **Orchestrateur**: Le composant central qui coordonne la boucle cognitive et la prise de décision
## Exigences
### Exigence 1: Détection d'Éléments d'UI
**User Story:** En tant que développeur RPA, je veux que le système détecte et identifie les éléments d'UI individuels à l'écran, afin de pouvoir interagir avec des boutons, champs et contrôles spécifiques plutôt que de me fier à une correspondance plein écran.
#### Critères d'Acceptation
1. QUAND le système capture une capture d'écran, ALORS le Système GeniusIA DOIT identifier tous les éléments d'UI interactifs présents à l'écran
2. QUAND un élément interactif est détecté, ALORS le Système GeniusIA DOIT extraire une capture locale (région recadrée) de cet élément
3. QUAND un élément d'UI est traité, ALORS le Système GeniusIA DOIT générer un embedding à partir de la capture locale
4. QUAND un élément d'UI est analysé, ALORS le Système GeniusIA DOIT utiliser le VLM pour générer une description textuelle de l'élément
5. QUAND les informations d'élément sont stockées, ALORS le Système GeniusIA DOIT créer un Descripteur d'Élément contenant (capture locale, embedding, description VLM, position écran)
### Exigence 2: Classification d'Éléments
**User Story:** En tant que développeur RPA, je veux que le système classifie les éléments d'UI par type, afin de pouvoir appliquer des stratégies d'interaction appropriées pour les boutons, champs, listes et autres contrôles.
#### Critères d'Acceptation
1. QUAND un élément d'UI est détecté, ALORS le Système GeniusIA DOIT le classifier dans l'un des types suivants : bouton, champ de texte, liste déroulante, onglet, case à cocher, bouton radio, lien, ou élément interactif générique
2. QUAND un élément est classifié, ALORS le Système GeniusIA DOIT utiliser à la fois les caractéristiques visuelles et l'analyse textuelle VLM
3. QUAND le type d'élément est ambigu, ALORS le Système GeniusIA DOIT assigner un score de confiance à la classification
4. QUAND les données d'élément sont stockées, ALORS le Système GeniusIA DOIT inclure le type d'élément et le score de confiance dans le Descripteur d'Élément
### Exigence 3: Compréhension Sémantique des Éléments
**User Story:** En tant que développeur RPA, je veux que le système comprenne ce que fait chaque élément d'UI, afin que les workflows puissent référencer les éléments par leur signification sémantique plutôt que par des coordonnées de pixels.
#### Critères d'Acceptation
1. QUAND un élément d'UI est analysé, ALORS le VLM DOIT générer une description sémantique telle que "Bouton 'Valider la facture' en bas à droite"
2. QUAND la sémantique d'élément est extraite, ALORS le Système GeniusIA DOIT identifier le label ou le contenu textuel de l'élément
3. QUAND le but de l'élément est déterminé, ALORS le Système GeniusIA DOIT inférer l'action ou la fonction à partir d'indices visuels et textuels
4. QUAND la localisation de l'élément est décrite, ALORS le Système GeniusIA DOIT fournir des informations de position relative (haut/bas, gauche/droite, près d'autres éléments)
5. QUAND plusieurs éléments similaires existent, ALORS le Système GeniusIA DOIT les différencier en utilisant des informations spatiales et contextuelles
### Exigence 4: Embedding d'État Multi-Modal
**User Story:** En tant que développeur RPA, je veux que le système crée un embedding unifié combinant toutes les informations disponibles sur l'état de l'écran, afin que la correspondance de workflow soit robuste face aux variations visuelles.
#### Critères d'Acceptation
1. QUAND un embedding d'état est généré, ALORS le Gestionnaire d'Embeddings DOIT combiner l'embedding visuel du screenshot, le texte extrait par VLM, le titre de fenêtre et le contexte workflow en un seul vecteur unifié
2. QUAND un screenshot est traité, ALORS le Système GeniusIA DOIT extraire le contenu textuel en utilisant le VLM
3. QUAND l'état d'écran est capturé, ALORS le Système GeniusIA DOIT inclure le titre de la fenêtre active
4. OÙ le contexte workflow est disponible, ALORS le Système GeniusIA DOIT inclure les métadonnées contextuelles (ID patient, numéro de facture, type de document, etc.)
5. QUAND l'embedding unifié est créé, ALORS le Gestionnaire d'Embeddings DOIT normaliser et pondérer chaque modalité de manière appropriée
### Exigence 5: Génération d'Empreinte d'État
**User Story:** En tant que développeur RPA, je veux que chaque état d'écran ait une empreinte unique et robuste, afin que le système puisse reconnaître de manière fiable les états même lorsque l'apparence visuelle varie légèrement.
#### Critères d'Acceptation
1. QUAND une empreinte d'état est générée, ALORS le Gestionnaire d'Embeddings DOIT produire une représentation vectorielle de dimension fixe
2. QUAND des empreintes d'état sont comparées, ALORS le Système GeniusIA DOIT utiliser la similarité cosinus ou une métrique de distance équivalente
3. QUAND les éléments visuels changent légèrement (couleur, taille, position), ALORS l'empreinte d'état DOIT rester suffisamment similaire pour la correspondance
4. QUAND le contenu sémantique change significativement, ALORS l'empreinte d'état DOIT différer suffisamment pour éviter les fausses correspondances
5. QUAND les empreintes d'état sont stockées, ALORS le Système GeniusIA DOIT les associer aux étapes de workflow et aux descripteurs d'éléments
### Exigence 6: Correspondance de Workflow au Niveau Élément
**User Story:** En tant que développeur RPA, je veux que les workflows correspondent en fonction de la présence et de l'état d'éléments d'UI spécifiques, afin que l'automatisation soit plus fiable que la comparaison d'images plein écran.
#### Critères d'Acceptation
1. QUAND une étape de workflow est mise en correspondance, ALORS le Système GeniusIA DOIT comparer les éléments d'UI détectés aux éléments attendus pour cette étape
2. QUAND une correspondance est évaluée, ALORS le Système GeniusIA DOIT considérer le type d'élément, la description sémantique et la position
3. QUAND plusieurs éléments sont requis, ALORS le Système GeniusIA DOIT vérifier que tous les éléments requis sont présents
4. QUAND des éléments optionnels existent, ALORS le Système GeniusIA DOIT augmenter la confiance de correspondance s'ils sont présents
5. QUAND des éléments sont manquants ou ne correspondent pas, ALORS le Système GeniusIA DOIT fournir un retour détaillé sur ce qui diffère
### Exigence 7: Intégration VLM pour l'Extraction de Texte
**User Story:** En tant que développeur RPA, je veux que le système extraie tout le texte visible des screenshots en utilisant le VLM, afin que le contenu textuel puisse être utilisé pour la correspondance et la prise de décision.
#### Critères d'Acceptation
1. QUAND un screenshot est traité, ALORS le Système GeniusIA DOIT utiliser Qwen3-VL pour extraire tout le texte visible
2. QUAND du texte est détecté, ALORS le Système GeniusIA DOIT préserver les informations spatiales sur l'emplacement du texte
3. QUAND du texte est extrait d'éléments d'UI, ALORS le Système GeniusIA DOIT associer le texte à l'élément correspondant
4. QUAND l'extraction de texte échoue ou est ambiguë, ALORS le Système GeniusIA DOIT enregistrer le problème et continuer le traitement
5. QUAND le texte extrait est stocké, ALORS le Système GeniusIA DOIT l'inclure à la fois dans les descripteurs d'éléments et les embeddings d'état
### Exigence 8: Représentation d'État Contextuelle
**User Story:** En tant que développeur RPA, je veux que le système inclue le contexte workflow dans les représentations d'état, afin que le même écran visuel puisse être interprété différemment selon la tâche en cours.
#### Critères d'Acceptation
1. OÙ le contexte workflow est disponible (ID patient, numéro de facture, type de document), ALORS le Système GeniusIA DOIT l'inclure dans l'embedding d'état
2. QUAND le contexte change, ALORS l'empreinte d'état DOIT refléter la différence contextuelle
3. QUAND des états sont comparés, ALORS le Système GeniusIA DOIT pondérer la similarité contextuelle de manière appropriée
4. QUAND le contexte est manquant, ALORS le Système GeniusIA DOIT quand même générer un embedding d'état valide en utilisant les informations disponibles
5. QUAND les étapes de workflow sont stockées, ALORS le Système GeniusIA DOIT capturer le contexte qui était présent pendant l'enregistrement
### Exigence 9: Compatibilité Arrière
**User Story:** En tant que mainteneur système, je veux que la nouvelle détection au niveau élément coexiste avec la correspondance plein écran existante, afin de pouvoir migrer progressivement sans casser les workflows existants.
#### Critères d'Acceptation
1. QUAND le système de détection d'éléments est activé, ALORS le Système GeniusIA DOIT continuer à supporter les workflows de correspondance plein écran existants
2. QUAND un workflow utilise des captures plein écran de l'ancien style, ALORS le Système GeniusIA DOIT les traiter en utilisant le système de correspondance legacy
3. QUAND un workflow utilise de nouveaux descripteurs au niveau élément, ALORS le Système GeniusIA DOIT utiliser le système de correspondance amélioré
4. QUAND des workflows sont migrés, ALORS le Système GeniusIA DOIT fournir des outils pour convertir les workflows plein écran en workflows au niveau élément
5. QUAND les deux systèmes sont actifs, ALORS le Système GeniusIA DOIT permettre la configuration pour préférer une approche plutôt que l'autre
### Exigence 10: Performance et Scalabilité
**User Story:** En tant qu'administrateur système, je veux que la détection d'éléments et l'embedding multi-modal soient performants, afin que le système RPA reste réactif pendant l'automatisation.
#### Critères d'Acceptation
1. QUAND des éléments d'UI sont détectés, ALORS le Système GeniusIA DOIT compléter le traitement en moins de 2 secondes pour un écran typique
2. QUAND des embeddings d'état sont générés, ALORS le Gestionnaire d'Embeddings DOIT compléter le traitement en moins de 1 seconde
3. QUAND des empreintes d'état sont comparées, ALORS le Système GeniusIA DOIT effectuer la recherche de similarité en moins de 100ms
4. QUAND l'extraction de texte VLM est traitée, ALORS le Système GeniusIA DOIT mettre en cache les résultats pour éviter un traitement redondant
5. QUAND la base de données d'éléments devient volumineuse, ALORS le Système GeniusIA DOIT maintenir la performance des requêtes via une indexation appropriée
### Exigence 11: Structure de Données UIElement
**User Story:** En tant que développeur système, je veux une structure de données standardisée pour les éléments d'UI, afin de pouvoir stocker, rechercher et manipuler les éléments de manière cohérente.
#### Critères d'Acceptation
1. QUAND un UIElement est créé, ALORS le Système GeniusIA DOIT lui assigner un identifiant stable basé sur (app_name + centre_bbox + label_normalized)
2. QUAND un UIElement est stocké, ALORS le Système GeniusIA DOIT inclure les champs suivants : element_id, type, role, bbox, label, visual (screenshot_path + embedding), text (raw + normalized + embedding), properties (is_clickable, is_focusable, is_dangerous), context (app_name, window_title, workflow_hint), et tags
3. QUAND un embedding visuel d'élément est généré, ALORS le Système GeniusIA DOIT stocker le provider (ex: openclip_ViT-B-32) et le vector_id (chemin vers le fichier .npy)
4. QUAND un embedding textuel d'élément est généré, ALORS le Système GeniusIA DOIT stocker le texte brut, le texte normalisé, le provider et le vector_id
5. QUAND un UIElement est sérialisé, ALORS le Système GeniusIA DOIT utiliser le format JSON avec tous les champs requis
### Exigence 12: Structure de Données ScreenState Enrichi
**User Story:** En tant que développeur système, je veux que le ScreenState contienne à la fois les éléments d'UI détectés et l'embedding d'état unifié, afin d'avoir une représentation complète de l'écran.
#### Critères d'Acceptation
1. QUAND un ScreenState est créé, ALORS le Système GeniusIA DOIT inclure les champs suivants : screen_state_id, timestamp, session_id, window (app_name, window_title, screen_resolution), raw (screenshot_path), perception (detected_text), ui_elements (liste), state_embedding (provider, vector_id, components), et context
2. QUAND des éléments d'UI sont détectés, ALORS le Système GeniusIA DOIT les stocker dans le champ ui_elements du ScreenState
3. QUAND un state_embedding est généré, ALORS le Système GeniusIA DOIT stocker le vecteur final ainsi que ses composantes (image_embedding, text_embedding, title_embedding, ui_embedding, context_embedding)
4. QUAND un ScreenState est sérialisé, ALORS le Système GeniusIA DOIT utiliser le format JSON avec tous les champs requis
5. QUAND un ScreenState est chargé, ALORS le Système GeniusIA DOIT pouvoir reconstruire tous les embeddings à partir des vector_id stockés
### Exigence 13: Pipeline de Détection d'Éléments
**User Story:** En tant que développeur système, je veux un pipeline clair pour transformer un screenshot en liste d'UIElement, afin de pouvoir maintenir et améliorer le processus de détection.
#### Critères d'Acceptation
1. QUAND un screenshot est capturé, ALORS le Système GeniusIA DOIT exécuter les étapes suivantes dans l'ordre : (1) proposer des régions d'intérêt, (2) caractériser chaque élément, (3) classifier type et rôle
2. QUAND des régions d'intérêt sont proposées, ALORS le Système GeniusIA DOIT utiliser au moins une des méthodes suivantes : détection de zones de texte, repérage de rectangles autour de texte, ou requête VLM pour zones cliquables
3. QUAND un élément est caractérisé, ALORS le Système GeniusIA DOIT extraire : crop image de la zone, embedding image, texte dans/autour de la zone, embedding texte, et position bbox
4. QUAND un élément est classifié, ALORS le Système GeniusIA DOIT déterminer le type (button, text_input, checkbox, etc.) et le rôle sémantique (primary_action, dangerous_action, search_field, etc.)
5. QUAND le pipeline échoue sur un élément, ALORS le Système GeniusIA DOIT enregistrer l'erreur et continuer avec les autres éléments
### Exigence 14: Pipeline de Fusion Multi-Modale
**User Story:** En tant que développeur système, je veux un pipeline clair pour créer un state_embedding à partir de multiples modalités, afin de pouvoir ajuster les pondérations et améliorer la robustesse.
#### Critères d'Acceptation
1. QUAND un state_embedding est généré, ALORS le Système GeniusIA DOIT calculer les composantes suivantes : image_embedding (screenshot entier), text_embedding (texte concaténé détecté), title_embedding (window_title), ui_embedding (moyenne des embeddings d'éléments importants), et context_embedding (vecteur de contexte workflow)
2. QUAND les composantes sont fusionnées, ALORS le Gestionnaire d'Embeddings DOIT normaliser chaque vecteur avant fusion
3. QUAND la fusion est effectuée, ALORS le Gestionnaire d'Embeddings DOIT utiliser une combinaison pondérée avec les poids configurables suivants par défaut : w_img=0.5, w_text=0.3, w_title=0.1, w_ui=0.1, w_ctx=0.1
4. QUAND le vecteur final est produit, ALORS le Gestionnaire d'Embeddings DOIT le normaliser pour avoir une norme unitaire
5. QUAND les composantes individuelles sont calculées, ALORS le Système GeniusIA DOIT les stocker séparément pour permettre le debug et l'analyse
### Exigence 15: Implémentation Progressive
**User Story:** En tant que mainteneur système, je veux pouvoir activer les nouvelles fonctionnalités progressivement, afin de minimiser les risques et de valider chaque étape.
#### Critères d'Acceptation
1. QUAND le système est en mode "light", ALORS le Système GeniusIA DOIT ajouter les champs ui_elements (vide) et state_embedding (image uniquement) au JSON sans changer la logique existante
2. QUAND le système est en mode "enrichi", ALORS le Système GeniusIA DOIT détecter les UIElement pour certains écrans configurés tout en maintenant la compatibilité avec le mode light
3. QUAND le système est en mode "complet", ALORS le Système GeniusIA DOIT calculer le state_embedding fusionné avec toutes les modalités
4. QUAND un mode est activé, ALORS le Système GeniusIA DOIT permettre la configuration via un fichier de configuration ou des variables d'environnement
5. QUAND un mode change, ALORS le Système GeniusIA DOIT continuer à lire les anciens formats de données tout en écrivant dans le nouveau format

388
.kiro/specs/ui-element-detection/tasks.md Normal file
View File

@@ -0,0 +1,388 @@
# Plan d'Implémentation - Détection d'Éléments UI et Fusion Multi-Modale
## Vue d'Ensemble
Ce plan implémente progressivement le système de détection d'éléments UI et de fusion multi-modale en 3 phases :
- **Phase 1 (Light)** : Structures de données et mode minimal
- **Phase 2 (Enrichi)** : Détection d'éléments basique
- **Phase 3 (Complet)** : Fusion multi-modale complète
## Tâches
- [x] 1. Phase 1 - Mode Light : Structures de Données de Base
- Créer les structures de données UIElement et EnrichedScreenState
- Ajouter les champs au JSON sans changer la logique existante
- Permettre la compatibilité arrière complète
- _Exigences: 11.1, 11.2, 11.5, 12.1, 12.4, 15.1_
- [x] 1.1 Créer les dataclasses pour UIElement
- Implémenter UIElement avec tous les champs (element_id, type, role, bbox, label, visual, text, properties, context, tags)
- Implémenter les sous-structures (VisualData, TextData, ElementProperties, ElementContext)
- Ajouter les méthodes de sérialisation/désérialisation JSON
- Implémenter la génération d'element_id stable basée sur hash(app_name + center_bbox + label_normalized)
- _Exigences: 11.1, 11.2, 11.3, 11.4, 11.5_
- [ ]* 1.2 Écrire les tests de propriété pour UIElement
- **Propriété 6: Stabilité des identifiants** - Pour tout UIElement créé deux fois avec mêmes paramètres, l'element_id doit être identique
- **Propriété 32: Complétude de la structure UIElement** - Tous les champs requis doivent être présents
- **Propriété 33: Round-trip de sérialisation UIElement** - Sérialisation puis désérialisation doit préserver tous les champs
- _Valide: Exigences 11.1, 11.2, 11.5_
- [x] 1.3 Créer les dataclasses pour EnrichedScreenState
- Implémenter EnrichedScreenState avec tous les champs (screen_state_id, timestamp, session_id, window, raw, perception, ui_elements, state_embedding, context)
- Implémenter les sous-structures (WindowInfo, RawData, PerceptionData, StateEmbedding, EmbeddingComponents, ContextData)
- Ajouter les méthodes de sérialisation/désérialisation JSON
- Assurer la compatibilité avec l'ancien format ScreenState
- _Exigences: 12.1, 12.2, 12.3, 12.4_
- [ ]* 1.4 Écrire les tests de propriété pour EnrichedScreenState
- **Propriété 34: Complétude de la structure ScreenState** - Tous les champs requis doivent être présents
- **Propriété 36: Round-trip de sérialisation ScreenState** - Les embeddings doivent être reconstruits correctement
- **Propriété 42: Compatibilité de lecture multi-mode** - Lecture des anciens formats sans erreur
- _Valide: Exigences 12.1, 12.4, 12.5, 15.5_
- [x] 1.5 Intégrer les nouvelles structures dans le système existant
- Modifier le code existant pour utiliser EnrichedScreenState au lieu de ScreenState
- Initialiser ui_elements comme liste vide par défaut
- Initialiser state_embedding avec image_embedding uniquement (mode light)
- Assurer que tous les workflows existants continuent de fonctionner
- _Exigences: 9.1, 15.1_
- [ ]* 1.6 Écrire les tests de compatibilité arrière
- **Propriété 25: Compatibilité arrière des workflows legacy** - Les anciens workflows doivent continuer à fonctionner
- Tester que les anciens fichiers JSON sont lisibles
- Tester que les nouveaux fichiers sont écrits avec les nouveaux champs
- _Valide: Exigences 9.1, 9.2, 15.1_
- [x] 2. Checkpoint - Vérifier que le mode Light fonctionne
- Assurer que tous les tests passent
- Vérifier que les workflows existants fonctionnent toujours
- Demander à l'utilisateur si des questions se posent
- [x] 3. Phase 2 - Mode Enrichi : Détection d'Éléments Basique
- Implémenter le pipeline de détection d'éléments
- Détecter les éléments pour certains écrans configurés
- Maintenir la compatibilité avec le mode light
- _Exigences: 1.1, 1.2, 1.3, 1.4, 1.5, 13.1, 13.2, 13.3, 13.4, 13.5, 15.2_
- [x] 3.1 Créer le composant RegionProposer
- Implémenter la détection de zones de texte (méthode rapide)
- Implémenter la détection de rectangles autour de texte (heuristique)
- Implémenter la requête VLM conditionnelle pour zones cliquables (coûteux)
- Implémenter la fusion et le nettoyage des régions (merge overlapping, filter invalid)
- Implémenter la logique _should_use_vlm pour décider quand utiliser le VLM
- _Exigences: 13.2_
- [ ]* 3.2 Écrire les tests pour RegionProposer
- Tester la détection de zones de texte sur images synthétiques
- Tester la fusion de régions qui se chevauchent
- Tester le filtrage de régions invalides (trop petites, hors écran)
- _Valide: Exigences 13.2_
- [x] 3.3 Créer le composant ElementCharacterizer
- Implémenter l'extraction de crop image pour chaque région
- Implémenter la génération d'embedding image via CLIP
- Implémenter l'extraction de texte dans/autour de la région via VLM
- Implémenter la génération d'embedding texte
- Implémenter l'extraction de position bbox
- _Exigences: 1.2, 1.3, 1.4, 13.3_
- [ ]* 3.4 Écrire les tests de propriété pour ElementCharacterizer
- **Propriété 1: Complétude de détection d'éléments** - Tous les champs requis doivent être extraits
- **Propriété 37: Complétude de la caractérisation** - Crop, embeddings, texte, bbox doivent être présents
- _Valide: Exigences 1.2, 1.3, 1.4, 13.3_
- [x] 3.5 Créer le composant ElementClassifier
- Implémenter la classification de type (button, text_input, checkbox, etc.)
- Implémenter l'inférence de rôle sémantique (primary_action, dangerous_action, search_field, etc.)
- Implémenter l'assignation de score de confiance
- Utiliser les caractéristiques visuelles et l'analyse textuelle VLM
- _Exigences: 2.1, 2.3, 2.4, 13.4_
- [ ]* 3.6 Écrire les tests de propriété pour ElementClassifier
- **Propriété 2: Validité des types d'éléments** - Le type doit être l'un des types valides
- **Propriété 3: Présence du score de confiance** - Score entre 0.0 et 1.0 doit être assigné
- **Propriété 38: Complétude de la classification** - Type et rôle doivent être présents
- _Valide: Exigences 2.1, 2.3, 2.4, 13.4_
- [x] 3.7 Créer le composant UIElementDetector principal
- Implémenter la méthode detect_elements qui orchestre le pipeline complet
- Intégrer RegionProposer, ElementCharacterizer et ElementClassifier
- Implémenter la gestion d'erreurs (continuer si un élément échoue)
- Implémenter le logging détaillé de chaque étape
- _Exigences: 1.1, 13.1, 13.5_
- [ ]* 3.8 Écrire les tests de propriété pour UIElementDetector
- **Propriété 1: Complétude de détection d'éléments** - Tous les éléments interactifs doivent être détectés
- **Propriété 39: Robustesse du pipeline** - Si 1 élément échoue, les N-1 autres doivent être produits
- _Valide: Exigences 1.1, 13.5_
- [x] 3.9 Intégrer UIElementDetector dans l'Orchestrator
- Ajouter un appel à UIElementDetector.detect_elements lors de la capture d'écran
- Stocker les UIElement détectés dans EnrichedScreenState.ui_elements
- Ajouter une configuration pour activer/désactiver la détection (mode enrichi)
- Implémenter la détection conditionnelle (seulement pour certains écrans configurés)
- _Exigences: 15.2_
- [ ]* 3.10 Écrire les tests d'intégration pour la détection
- Tester le pipeline complet : screenshot → UIElements
- Tester avec différents types d'écrans (formulaires, tableaux, menus)
- Tester la performance (< 2 secondes pour écran typique)
- _Valide: Exigences 1.1, 10.1_
- [x] 4. Checkpoint - Vérifier que le mode Enrichi fonctionne
- Assurer que tous les tests passent
- Vérifier que les éléments sont détectés correctement sur des écrans de test
- Demander à l'utilisateur si des questions se posent
- [x] 5. Phase 3 - Mode Complet : Fusion Multi-Modale
- Implémenter le gestionnaire d'embeddings multi-modaux
- Calculer le state_embedding fusionné avec toutes les modalités
- Intégrer dans le workflow matcher
- _Exigences: 4.1, 4.2, 4.3, 4.4, 4.5, 5.1, 5.2, 5.3, 5.4, 14.1, 14.2, 14.3, 14.4, 14.5, 15.3_
- [x] 5.1 Créer le composant MultiModalEmbeddingManager
- Implémenter la méthode create_state_embedding
- Calculer image_embedding (screenshot entier via CLIP)
- Calculer text_embedding (texte concaténé via CLIP text)
- Calculer title_embedding (window_title via CLIP text)
- Calculer ui_embedding (moyenne des embeddings d'éléments importants)
- Calculer context_embedding (vecteur de contexte workflow)
- _Exigences: 4.1, 4.2, 4.3, 4.4, 14.1_
- [ ]* 5.2 Écrire les tests de propriété pour les composantes individuelles
- **Propriété 7: Structure complète du state embedding** - Toutes les composantes doivent être présentes
- **Propriété 8: Extraction de texte systématique** - Le texte doit être extrait pour tout screenshot
- **Propriété 9: Présence du titre de fenêtre** - window_title doit être présent
- **Propriété 10: Inclusion du contexte workflow** - Le contexte doit être inclus si disponible
- _Valide: Exigences 4.1, 4.2, 4.3, 4.4, 14.1_
- [x] 5.3 Implémenter la normalisation des composantes
- Normaliser chaque vecteur individuel (norme L2 = 1.0) avant fusion
- Implémenter la méthode _normalize
- Ajouter des assertions pour vérifier la normalisation
- _Exigences: 4.5, 14.2_
- [ ]* 5.4 Écrire les tests de propriété pour la normalisation
- **Propriété 40: Normalisation des composantes** - Chaque composante doit avoir norme L2 = 1.0 avant fusion
- Tester avec différents vecteurs d'entrée
- _Valide: Exigences 14.2_
- [x] 5.5 Implémenter la fusion pondérée des composantes
- Implémenter la combinaison pondérée avec poids configurables
- Poids par défaut : w_img=0.5, w_text=0.3, w_title=0.1, w_ui=0.1, w_ctx=0.1
- Normaliser le vecteur final (norme L2 = 1.0)
- Stocker les composantes individuelles séparément pour debug
- _Exigences: 4.5, 14.3, 14.4, 14.5_
- [ ]* 5.6 Écrire les tests de propriété pour la fusion
- **Propriété 11: Normalisation des embeddings** - Le vecteur final doit avoir norme L2 = 1.0
- **Propriété 12: Dimension fixe des embeddings** - La dimension doit être constante
- **Propriété 41: Stockage des composantes** - Les composantes doivent être stockées séparément
- _Valide: Exigences 4.5, 5.1, 14.4, 14.5_
- [x] 5.7 Implémenter le calcul de ui_embedding
- Filtrer les éléments importants (primary_action, is_clickable)
- Calculer la moyenne des embeddings visuels
- Gérer le cas où aucun élément n'est présent (retourner vecteur zéro)
- _Exigences: 14.1_
- [x] 5.8 Implémenter le calcul de context_embedding
- Encoder les métadonnées de contexte (workflow_id, flags métier)
- Projeter en vecteur de dimension appropriée
- Gérer le cas où le contexte est manquant
- _Exigences: 4.4, 8.1, 8.4_
- [ ]* 5.9 Écrire les tests de propriété pour le contexte
- **Propriété 22: Sensibilité au contexte** - Contextes différents doivent produire embeddings différents
- **Propriété 23: Robustesse en absence de contexte** - Un embedding valide doit être généré même sans contexte
- _Valide: Exigences 8.2, 8.4_
- [x] 5.10 Intégrer MultiModalEmbeddingManager dans l'Orchestrator
- Appeler create_state_embedding lors de la capture d'écran
- Stocker le state_embedding dans EnrichedScreenState
- Ajouter une configuration pour activer/désactiver la fusion multi-modale (mode complet)
- _Exigences: 15.3_
- [ ]* 5.11 Écrire les tests d'intégration pour la fusion multi-modale
- Tester le pipeline complet : screenshot → state_embedding fusionné
- Tester la performance (< 1 seconde pour génération d'embedding)
- _Valide: Exigences 10.2_
- [x] 6. Checkpoint - Vérifier que le mode Complet fonctionne
- Assurer que tous les tests passent
- Vérifier que les state_embeddings sont générés correctement
- Demander à l'utilisateur si des questions se posent
- [-] 7. Améliorer le WorkflowMatcher pour utiliser les éléments
- Créer EnhancedWorkflowMatcher qui supporte le matching au niveau élément
- Maintenir le matcher legacy pour compatibilité
- Implémenter le routage automatique (legacy vs enhanced)
- _Exigences: 6.1, 6.2, 6.3, 6.4, 6.5, 9.2, 9.3_
- [ ] 7.1 Créer la classe EnhancedWorkflowMatcher
- Implémenter match_workflow_step qui route vers matching élément ou legacy
- Implémenter _has_element_descriptors pour détecter le type de workflow
- Implémenter _match_by_elements pour matching basé sur éléments
- Implémenter _match_legacy pour compatibilité arrière
- _Exigences: 6.1, 9.2, 9.3_
- [ ]* 7.2 Écrire les tests de propriété pour le routage
- **Propriété 26: Routage correct des workflows** - Workflows avec descripteurs → matcher amélioré, sans → legacy
- Tester avec différents types de workflows
- _Valide: Exigences 9.2, 9.3_
- [x] 7.3 Implémenter la comparaison de state_embeddings
- Calculer la similarité cosinus entre embeddings
- Implémenter _compare_state_embeddings
- Retourner un score entre 0.0 et 1.0
- _Exigences: 5.2, 6.2_
- [ ]* 7.4 Écrire les tests de propriété pour la comparaison
- **Propriété 13: Robustesse aux variations visuelles légères** - Similarité ≥ 0.85 pour variations légères
- **Propriété 14: Discrimination sémantique** - Similarité ≤ 0.70 pour écrans différents
- Tester la performance (< 100ms par comparaison)
- _Valide: Exigences 5.2, 5.3, 5.4, 10.3_
- [x] 7.5 Implémenter la comparaison d'éléments requis
- Implémenter _compare_required_elements
- Implémenter _elements_match pour vérifier correspondance type/rôle/sémantique/position
- Calculer le score de correspondance (nombre d'éléments matchés / nombre requis)
- _Exigences: 6.1, 6.2, 6.3_
- [ ]* 7.6 Écrire les tests de propriété pour la correspondance d'éléments
- **Propriété 16: Vérification des éléments requis** - Score < 0.5 si éléments manquants
- **Propriété 17: Bonus des éléments optionnels** - Score augmente avec éléments optionnels
- _Valide: Exigences 6.3, 6.4_
- [x] 7.7 Implémenter le feedback détaillé sur échec
- Créer MatchResult avec liste de différences
- Identifier les éléments manquants, types incorrects, positions incorrectes
- Formater un message d'erreur lisible
- _Exigences: 6.5_
- [ ]* 7.8 Écrire les tests de propriété pour le feedback
- **Propriété 18: Feedback détaillé sur échec** - Liste non-vide de différences pour tout échec
- Tester avec différents types d'échecs
- _Valide: Exigences 6.5_
- [x] 7.9 Intégrer EnhancedWorkflowMatcher dans l'Orchestrator
- Remplacer l'ancien WorkflowMatcher par EnhancedWorkflowMatcher
- Passer le legacy_matcher en paramètre pour compatibilité
- Configurer les poids de matching (weight_state, weight_elements)
- _Exigences: 9.1, 9.2, 9.3_
- [x] 7.10 Écrire les tests d'intégration pour le matching
- Tester le matching avec workflows legacy (compatibilité)
- Tester le matching avec workflows enrichis (éléments)
- Tester le routage automatique
- _Valide: Exigences 9.1, 9.2, 9.3_
- [x] 8. Checkpoint - Vérifier que le matching amélioré fonctionne
- Assurer que tous les tests passent
- Vérifier que les workflows legacy fonctionnent toujours
- Vérifier que les nouveaux workflows utilisent le matching amélioré
- Demander à l'utilisateur si des questions se posent
- [ ] 9. Optimisations et Performance
- Implémenter le cache pour le VLM
- Optimiser les requêtes d'éléments
- Ajouter des métriques de monitoring
- _Exigences: 10.1, 10.2, 10.3, 10.4, 10.5_
- [ ] 9.1 Implémenter le cache VLM
- Créer un cache basé sur hash du screenshot
- Implémenter une politique d'éviction LRU
- Persister le cache entre sessions (optionnel)
- Mesurer le taux de cache hit
- _Exigences: 10.4_
- [ ]* 9.2 Écrire les tests de propriété pour le cache
- **Propriété 30: Efficacité du cache VLM** - Deuxième traitement ≤ 10% du temps du premier
- Tester avec différents screenshots
- _Valide: Exigences 10.4_
- [ ] 9.3 Optimiser les requêtes d'éléments
- Créer un index sur element_id pour recherche rapide
- Implémenter une recherche par type et rôle
- Mesurer les temps de requête
- _Exigences: 10.5_
- [ ]* 9.4 Écrire les tests de propriété pour la scalabilité
- **Propriété 31: Scalabilité des requêtes** - Temps ≤ 50ms pour base de 100k éléments
- Tester avec différentes tailles de base de données
- _Valide: Exigences 10.5_
- [ ] 9.5 Ajouter des métriques de monitoring
- Nombre d'éléments détectés par screenshot
- Temps de chaque étape du pipeline
- Taux de cache hit pour le VLM
- Distribution des types d'éléments
- Scores de matching moyens
- _Exigences: 10.1, 10.2, 10.3_
- [ ]* 9.6 Écrire les tests de performance
- **Propriété 27: Performance de détection** - ≤ 2 secondes pour écran typique
- **Propriété 28: Performance de génération d'embedding** - ≤ 1 seconde
- **Propriété 29: Performance de comparaison** - ≤ 100ms
- _Valide: Exigences 10.1, 10.2, 10.3_
- [ ] 10. Outils et Utilitaires
- Créer un outil de migration de workflows
- Créer un mode debug visuel
- Créer un outil de configuration
- _Exigences: 9.4, 9.5, 15.4_
- [ ] 10.1 Créer un outil de migration de workflows
- Convertir les workflows plein écran en workflows au niveau élément
- Détecter automatiquement les éléments dans les anciens screenshots
- Générer les descripteurs d'éléments
- Sauvegarder les workflows migrés
- _Exigences: 9.4_
- [ ] 10.2 Créer un mode debug visuel
- Sauvegarder des screenshots annotés avec bounding boxes
- Afficher les types et rôles détectés
- Afficher les scores de confiance
- Afficher les embeddings (visualisation PCA/t-SNE)
- _Exigences: Design - Logging et Debug_
- [ ] 10.3 Créer un outil de configuration
- Permettre la configuration via fichier YAML ou variables d'environnement
- Configurer les modes (light, enrichi, complet)
- Configurer les poids de fusion
- Configurer les seuils de matching
- Configurer l'activation du VLM
- _Exigences: 15.4_
- [ ] 11. Documentation et Tests Finaux
- Documenter l'API des nouveaux composants
- Créer des exemples d'utilisation
- Vérifier la couverture de tests
- _Exigences: Toutes_
- [ ] 11.1 Documenter l'API
- Documenter UIElement, EnrichedScreenState
- Documenter UIElementDetector, MultiModalEmbeddingManager, EnhancedWorkflowMatcher
- Créer des docstrings complètes
- Générer la documentation API (Sphinx)
- _Exigences: Toutes_
- [ ] 11.2 Créer des exemples d'utilisation
- Exemple de détection d'éléments sur un screenshot
- Exemple de génération de state_embedding
- Exemple de matching de workflow
- Exemple de migration de workflow
- _Exigences: Toutes_
- [ ] 11.3 Vérifier la couverture de tests
- Vérifier que toutes les propriétés sont testées
- Vérifier la couverture de code (> 80%)
- Ajouter des tests manquants si nécessaire
- _Exigences: Toutes_
- [ ] 12. Checkpoint Final - Validation Complète
- Assurer que tous les tests passent
- Vérifier que toutes les exigences sont satisfaites
- Tester sur des workflows réels
- Demander à l'utilisateur si des questions se posent

214
.kiro/specs/workflow-detection-fix/design.md Normal file
View File

@@ -0,0 +1,214 @@
# Design Document - Workflow Detection Fix
## Overview
This design addresses the critical bugs preventing workflow detection in GeniusIA v2. The main issues are:
1. SessionManager and WorkflowDetector are not integrated into the Orchestrator
2. VisionAnalysis has an attribute name bug (`self.llm_manager` vs `self.llm`)
3. No workflow persistence mechanism exists
The solution integrates these components into the existing cognitive loop and fixes the bugs.
## Architecture
### Current Architecture (Broken)
```
Orchestrator
├─ EventCapture (captures actions)
├─ VisionAnalysis (BROKEN - wrong attribute)
├─ SuggestionManager (never receives workflows)
└─ LearningManager
```
### Fixed Architecture
```
Orchestrator
├─ EventCapture (captures actions)
├─ SessionManager (NEW - segments actions)
│ └─ WorkflowDetector (NEW - detects patterns)
├─ VisionAnalysis (FIXED - correct attribute)
├─ SuggestionManager (receives workflow notifications)
└─ LearningManager
```
## Components and Interfaces
### 1. Orchestrator Integration
**Changes Required:**
- Import SessionManager and WorkflowDetector
- Initialize both components in `__init__`
- Pass actions to SessionManager in the cognitive loop
- Connect WorkflowDetector callbacks to SuggestionManager
**New Attributes:**
```python
self.session_manager: SessionManager
self.workflow_detector: WorkflowDetector
```
**New Method:**
```python
def _on_workflow_detected(self, workflow: Dict[str, Any]) -> None:
"""Callback when a workflow is detected."""
# Notify suggestion manager
# Log workflow details
# Persist workflow
```
### 2. SessionManager Integration
**Initialization:**
```python
self.session_manager = SessionManager(
logger=logger,
config=config
)
```
**Usage in Cognitive Loop:**
```python
# After action is captured
session = self.session_manager.add_action(action_data)
if session and session.is_complete:
self.workflow_detector.analyze_session(session)
```
### 3. WorkflowDetector Integration
**Initialization:**
```python
self.workflow_detector = WorkflowDetector(
embeddings_manager=learning_manager.embeddings_manager,
logger=logger,
config=config
)
self.workflow_detector.on_workflow_detected = self._on_workflow_detected
```
**Workflow Persistence:**
- Save to `data/user_profiles/workflows/workflow_{id}.json`
- Load on startup
- Update confidence scores on execution
### 4. VisionAnalysis Bug Fix
**Current Bug:**
```python
if self.llm_manager: # WRONG - attribute is self.llm
response = self.llm_manager.generate_with_vision(...)
```
**Fixed:**
```python
if self.llm: # CORRECT
response = self.llm.generate_with_vision(...)
```
## Data Models
### Session Model (Existing)
```python
@dataclass
class Session:
session_id: str
start_time: datetime
end_time: Optional[datetime]
actions: List[Dict[str, Any]]
window: Optional[str]
```
### Workflow Model (New)
```python
@dataclass
class Workflow:
workflow_id: str
name: str
pattern: List[str] # Action signatures
confidence: float
repetitions: int
last_seen: datetime
window: str
```
## Error Handling
### VisionAnalysis Errors
- Catch all exceptions in `analyze_action`
- Log errors with context
- Return partial signature on failure
- Continue processing other actions
### SessionManager Errors
- Handle invalid action data gracefully
- Log session creation failures
- Don't crash on timeout issues
### WorkflowDetector Errors
- Handle embedding comparison failures
- Log pattern matching errors
- Continue processing other sessions
## 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: Action forwarding to SessionManager
*For any* valid user action processed by the Orchestrator, the action should be passed to the SessionManager for segmentation.
**Validates: Requirements 1.1**
### Property 2: Session grouping by time and context
*For any* sequence of actions with timestamps and window contexts, actions within the time window threshold and same window should be grouped into the same session.
**Validates: Requirements 1.2**
### Property 3: Completed sessions trigger workflow analysis
*For any* completed session, the WorkflowDetector should receive the session for pattern analysis.
**Validates: Requirements 1.3**
### Property 4: Workflow detection triggers notifications
*For any* detected workflow pattern, the SuggestionManager callback should be invoked with the workflow details.
**Validates: Requirements 1.4**
### Property 5: Workflow notifications generate suggestions
*For any* workflow notification received by SuggestionManager, at least one suggestion should be created for the user.
**Validates: Requirements 1.5**
### Property 6: VisionAnalysis error resilience
*For any* error encountered during VisionAnalysis, the system should log the error and continue processing without crashing.
**Validates: Requirements 2.2**
### Property 7: Action signature completeness
*For any* action analyzed by VisionAnalysis, the resulting signature should contain both visual embeddings and element descriptions (or defaults if LLM unavailable).
**Validates: Requirements 2.3**
### Property 8: Workflow persistence
*For any* detected workflow, a corresponding JSON file should be created in the user profile workflows directory with all workflow details.
**Validates: Requirements 3.1**
### Property 9: Confidence score updates
*For any* workflow that is executed successfully, its confidence score should increase.
**Validates: Requirements 3.3**
### Property 10: Session logging completeness
*For any* session created by SessionManager, a log entry should be created containing the session ID and action count.
**Validates: Requirements 4.1**
### Property 11: Workflow detection logging
*For any* workflow detected by WorkflowDetector, a log entry should be created containing the workflow pattern and confidence score.
**Validates: Requirements 4.2**
### Property 12: Error logging with context
*For any* workflow detection failure, a log entry should be created containing the error message and relevant context.
**Validates: Requirements 4.3**
## Testing Strategy
### Unit Tests
- Test SessionManager action grouping with specific examples
- Test WorkflowDetector pattern matching with known patterns
- Test VisionAnalysis attribute access (bug fix verification)
- Test Orchestrator integration points with mocks
### Property-Based Tests
We will use Hypothesis for property-based testing in Python. Each property above will be implemented as a property-based test that runs 100+ iterations with randomly generated inputs to verify the correctness properties hold across all valid inputs.

60
.kiro/specs/workflow-detection-fix/requirements.md Normal file
View File

@@ -0,0 +1,60 @@
# Requirements Document - Workflow Detection Fix
## Introduction
This document specifies the requirements for fixing the workflow detection system in GeniusIA v2. The system currently fails to detect workflows because the SessionManager and WorkflowDetector components are not integrated into the main Orchestrator, and there is a critical bug in VisionAnalysis that prevents action analysis.
## Glossary
- **Orchestrator**: The main cognitive loop that coordinates all system components
- **SessionManager**: Component that segments user actions into logical sessions
- **WorkflowDetector**: Component that identifies repeated patterns in sessions
- **VisionAnalysis**: Component that analyzes visual regions around user actions
- **SuggestionManager**: Component that generates suggestions based on detected workflows
- **Action**: A user interaction event (click, keypress, etc.)
- **Session**: A group of related actions within a time window
- **Workflow**: A repeated pattern of actions that can be automated
## Requirements
### Requirement 1
**User Story:** As a user, I want the system to detect my repeated action sequences, so that it can learn my workflows and suggest automations.
#### Acceptance Criteria
1. WHEN the Orchestrator processes user actions THEN the system SHALL pass those actions to the SessionManager for segmentation
2. WHEN the SessionManager receives actions THEN the system SHALL group them into sessions based on time windows and window context
3. WHEN a session is completed THEN the system SHALL pass it to the WorkflowDetector for pattern analysis
4. WHEN the WorkflowDetector identifies a repeated pattern THEN the system SHALL notify the SuggestionManager
5. WHEN the SuggestionManager receives a workflow notification THEN the system SHALL generate appropriate suggestions for the user
### Requirement 2
**User Story:** As a developer, I want the VisionAnalysis component to work correctly, so that action signatures can be created and compared.
#### Acceptance Criteria
1. WHEN VisionAnalysis analyzes an action THEN the system SHALL use the correct attribute name for the LLM manager
2. WHEN VisionAnalysis encounters an error THEN the system SHALL log the error and continue processing
3. WHEN VisionAnalysis creates an action signature THEN the system SHALL include visual embeddings and element descriptions
### Requirement 3
**User Story:** As a user, I want the system to persist detected workflows, so that they are available across sessions.
#### Acceptance Criteria
1. WHEN a workflow is detected THEN the system SHALL save it to the user profile directory
2. WHEN the system starts THEN the system SHALL load previously detected workflows
3. WHEN a workflow is executed successfully THEN the system SHALL update its confidence score
### Requirement 4
**User Story:** As a developer, I want comprehensive logging of the workflow detection process, so that I can debug issues.
#### Acceptance Criteria
1. WHEN actions are segmented into sessions THEN the system SHALL log session creation with action count
2. WHEN workflows are detected THEN the system SHALL log workflow details including pattern and confidence
3. WHEN workflow detection fails THEN the system SHALL log the error with context

114
.kiro/specs/workflow-detection-fix/tasks.md Normal file
View File

@@ -0,0 +1,114 @@
# Implementation Plan - Workflow Detection Fix
- [x] 1. Fix VisionAnalysis attribute bug
- Fix the `self.llm_manager` to `self.llm` attribute references
- Add error handling around LLM calls
- Ensure action signatures include all required fields
- _Requirements: 2.1, 2.2, 2.3_
- [ ]* 1.1 Write unit test for VisionAnalysis attribute fix
- Verify no AttributeError is raised when LLM is provided
- Test with and without LLM manager
- _Requirements: 2.1_
- [ ]* 1.2 Write property test for VisionAnalysis error handling
- **Property 6: VisionAnalysis error resilience**
- **Validates: Requirements 2.2**
- [ ]* 1.3 Write property test for action signature completeness
- **Property 7: Action signature completeness**
- **Validates: Requirements 2.3**
- [x] 2. Integrate SessionManager into Orchestrator
- Import SessionManager in orchestrator.py
- Initialize SessionManager in Orchestrator.__init__
- Add action forwarding in the cognitive loop
- Connect session completion callback
- _Requirements: 1.1, 1.2_
- [ ]* 2.1 Write property test for action forwarding
- **Property 1: Action forwarding to SessionManager**
- **Validates: Requirements 1.1**
- [ ]* 2.2 Write property test for session grouping
- **Property 2: Session grouping by time and context**
- **Validates: Requirements 1.2**
- [x] 3. Integrate WorkflowDetector into Orchestrator
- Import WorkflowDetector in orchestrator.py
- Initialize WorkflowDetector in Orchestrator.__init__
- Connect SessionManager to WorkflowDetector
- Implement _on_workflow_detected callback
- _Requirements: 1.3, 1.4_
- [ ]* 3.1 Write property test for session forwarding to WorkflowDetector
- **Property 3: Completed sessions trigger workflow analysis**
- **Validates: Requirements 1.3**
- [ ]* 3.2 Write property test for workflow notifications
- **Property 4: Workflow detection triggers notifications**
- **Validates: Requirements 1.4**
- [x] 4. Connect WorkflowDetector to SuggestionManager
- Implement workflow notification in _on_workflow_detected
- Ensure SuggestionManager receives workflow data
- Add logging for workflow detection events
- _Requirements: 1.5, 4.2_
- [ ]* 4.1 Write property test for suggestion generation
- **Property 5: Workflow notifications generate suggestions**
- **Validates: Requirements 1.5**
- [ ]* 4.2 Write property test for workflow detection logging
- **Property 11: Workflow detection logging**
- **Validates: Requirements 4.2**
- [x] 5. Implement workflow persistence
- Create workflow save method in WorkflowDetector
- Save workflows to data/user_profiles/workflows/
- Implement workflow loading on startup
- Add confidence score update mechanism
- _Requirements: 3.1, 3.2, 3.3_
- [ ]* 5.1 Write property test for workflow persistence
- **Property 8: Workflow persistence**
- **Validates: Requirements 3.1**
- [ ]* 5.2 Write unit test for workflow loading
- Create test workflow files
- Verify they are loaded on startup
- _Requirements: 3.2_
- [ ]* 5.3 Write property test for confidence score updates
- **Property 9: Confidence score updates**
- **Validates: Requirements 3.3**
- [ ] 6. Add comprehensive logging
- Add session creation logging in SessionManager
- Add workflow detection logging in WorkflowDetector
- Add error logging with context
- _Requirements: 4.1, 4.3_
- [ ]* 6.1 Write property test for session logging
- **Property 10: Session logging completeness**
- **Validates: Requirements 4.1**
- [ ]* 6.2 Write property test for error logging
- **Property 12: Error logging with context**
- **Validates: Requirements 4.3**
- [x] 7. Checkpoint - Ensure all tests pass
- Ensure all tests pass, ask the user if questions arise.
- **Status**: ✅ Intégration complète effectuée
- EventCapture passe maintenant les actions au SessionManager
- SessionManager segmente les actions en sessions
- WorkflowDetector analyse les sessions et détecte les patterns
- SuggestionManager reçoit les notifications de workflows
- Orchestrator coordonne tous les composants
- [ ] 8. End-to-end integration test
- Create test script that simulates repeated actions
- Verify sessions are created
- Verify workflows are detected
- Verify suggestions are generated
- _Requirements: 1.1, 1.2, 1.3, 1.4, 1.5_

1419
.kiro/specs/workflow-graph-implementation/design.md Normal file
View File

File diff suppressed because it is too large Load Diff

224
.kiro/specs/workflow-graph-implementation/requirements.md Normal file
View File

@@ -0,0 +1,224 @@
# Document de Requirements - Workflow Graph Implementation
## Introduction
Ce document définit les exigences pour l'implémentation de l'architecture Workflow Graph du système RPA Vision V2. Le système transforme progressivement des captures d'écran brutes en workflows sémantiques appris, permettant une automatisation basée sur la compréhension visuelle plutôt que sur des coordonnées de clics.
L'architecture suit une approche en 5 couches : RawSession (capture brute) → ScreenState (analyse multi-modale) → UIElement Detection (détection sémantique) → State Embedding (fusion multi-modale) → Workflow Graph (modélisation en graphe avec apprentissage progressif).
## Glossaire
- **System** : Le système RPA Vision V2
- **ScreenState** : Représentation structurée d'un état d'écran à 4 niveaux (Raw, Perception, Sémantique UI, Contexte Métier)
- **UIElement** : Élément d'interface détecté avec type, rôle et embeddings
- **State Embedding** : Vecteur unique (fingerprint) fusionnant toutes les modalités d'un écran
- **WorkflowNode** : Template d'état d'écran dans un graphe de workflow
- **WorkflowEdge** : Transition (action) entre deux nodes
- **Workflow Graph** : Graphe complet modélisant un workflow avec états d'apprentissage
- **Learning State** : État de progression (OBSERVATION, COACHING, AUTO_CANDIDATE, AUTO_CONFIRMÉ)
- **RawSession** : Enregistrement brut des événements utilisateur avec screenshots
- **Embedding** : Vecteur numérique représentant une modalité (image, texte, UI)
- **FAISS Index** : Index de recherche de similarité pour embeddings
- **VLM** : Vision-Language Model (modèle vision-langage)
## Requirements
### Requirement 1
**User Story:** En tant que développeur système, je veux capturer fidèlement les sessions utilisateur avec tous les événements et screenshots, afin de pouvoir analyser et apprendre les workflows.
#### Acceptance Criteria
1. WHEN THE System captures a user session THEN THE System SHALL record all mouse events with precise timestamps and window context
2. WHEN THE System captures a user session THEN THE System SHALL record all keyboard events with key combinations and window context
3. WHEN THE System captures a user session THEN THE System SHALL take screenshots at each significant event with unique identifiers
4. WHEN THE System saves a RawSession THEN THE System SHALL serialize it to JSON format with schema version "rawsession_v1"
5. WHEN THE System loads a RawSession THEN THE System SHALL deserialize it from JSON and validate schema compatibility
### Requirement 2
**User Story:** En tant que développeur système, je veux transformer chaque screenshot en ScreenState structuré à 4 niveaux, afin d'avoir une représentation riche et exploitable de l'état d'écran.
#### Acceptance Criteria
1. WHEN THE System processes a screenshot THEN THE System SHALL create a ScreenState with Raw level containing image path and metadata
2. WHEN THE System processes a screenshot THEN THE System SHALL create Perception level with image embedding using OpenCLIP
3. WHEN THE System processes a screenshot THEN THE System SHALL detect text using VLM and create text embeddings
4. WHEN THE System processes a screenshot THEN THE System SHALL detect UI elements and create Sémantique UI level
5. WHEN THE System processes a screenshot THEN THE System SHALL extract window context and create Contexte Métier level
6. WHEN THE System saves a ScreenState THEN THE System SHALL serialize it to JSON with all 4 levels preserved
### Requirement 3
**User Story:** En tant que développeur système, je veux détecter les éléments UI de manière sémantique avec types et rôles, afin de pouvoir les identifier et les manipuler indépendamment de leur position exacte.
#### Acceptance Criteria
1. WHEN THE System detects UI elements THEN THE System SHALL identify regions of interest using VLM
2. WHEN THE System detects UI elements THEN THE System SHALL classify each element with a semantic type (button, text_input, checkbox, etc.)
3. WHEN THE System detects UI elements THEN THE System SHALL assign a semantic role to each element (primary_action, cancel, form_input, etc.)
4. WHEN THE System detects UI elements THEN THE System SHALL extract visual features (dominant color, shape, size category)
5. WHEN THE System detects UI elements THEN THE System SHALL generate dual embeddings (image embedding and text embedding) for each element
6. WHEN THE System detects UI elements THEN THE System SHALL compute a confidence score for each detection
7. WHEN THE System saves UIElements THEN THE System SHALL serialize them to JSON with all attributes and embeddings references
### Requirement 4
**User Story:** En tant que développeur système, je veux fusionner toutes les modalités d'un écran en un State Embedding unique, afin de pouvoir comparer et matcher des états d'écran de manière robuste.
#### Acceptance Criteria
1. WHEN THE System creates a State Embedding THEN THE System SHALL compute image embedding from the full screenshot
2. WHEN THE System creates a State Embedding THEN THE System SHALL compute text embedding from all detected text concatenated
3. WHEN THE System creates a State Embedding THEN THE System SHALL compute title embedding from window title
4. WHEN THE System creates a State Embedding THEN THE System SHALL compute UI embedding by averaging all UIElement embeddings
5. WHEN THE System creates a State Embedding THEN THE System SHALL fuse all embeddings using weighted combination with configurable weights
6. WHEN THE System creates a State Embedding THEN THE System SHALL normalize the final embedding vector
7. WHEN THE System compares two State Embeddings THEN THE System SHALL compute cosine similarity between vectors
8. WHEN THE System saves a State Embedding THEN THE System SHALL store the vector in FAISS index and save metadata to JSON
### Requirement 5
**User Story:** En tant que développeur système, je veux modéliser les workflows comme des graphes explicites avec Nodes et Edges, afin de représenter clairement les états et transitions.
#### Acceptance Criteria
1. WHEN THE System creates a WorkflowNode THEN THE System SHALL define a screen template with window constraints
2. WHEN THE System creates a WorkflowNode THEN THE System SHALL define required text patterns for matching
3. WHEN THE System creates a WorkflowNode THEN THE System SHALL define required UI elements with roles and types
4. WHEN THE System creates a WorkflowNode THEN THE System SHALL compute an embedding prototype from sample ScreenStates
5. WHEN THE System creates a WorkflowNode THEN THE System SHALL set a minimum similarity threshold for matching
6. WHEN THE System saves a WorkflowNode THEN THE System SHALL serialize it to JSON with all template constraints
### Requirement 6
**User Story:** En tant que développeur système, je veux définir les transitions entre nodes comme des WorkflowEdges avec actions sémantiques, afin de spécifier comment naviguer dans le workflow.
#### Acceptance Criteria
1. WHEN THE System creates a WorkflowEdge THEN THE System SHALL define source and target nodes
2. WHEN THE System creates a WorkflowEdge THEN THE System SHALL define action type (mouse_click, key_press, text_input, compound)
3. WHEN THE System creates a WorkflowEdge THEN THE System SHALL define target element by semantic role rather than coordinates
4. WHEN THE System creates a WorkflowEdge THEN THE System SHALL define selection policy for target element (first, last, by_similarity)
5. WHEN THE System creates a WorkflowEdge THEN THE System SHALL define pre-conditions and post-conditions for validation
6. WHEN THE System creates a WorkflowEdge THEN THE System SHALL track execution statistics (success count, failure count, avg time)
7. WHEN THE System saves a WorkflowEdge THEN THE System SHALL serialize it to JSON with all action details and stats
### Requirement 7
**User Story:** En tant que développeur système, je veux assembler Nodes et Edges en Workflow Graph complet avec métadonnées, afin d'avoir une représentation complète du workflow.
#### Acceptance Criteria
1. WHEN THE System creates a Workflow Graph THEN THE System SHALL define entry nodes and end nodes
2. WHEN THE System creates a Workflow Graph THEN THE System SHALL validate that all edges reference existing nodes
3. WHEN THE System creates a Workflow Graph THEN THE System SHALL detect cycles and branching in the graph
4. WHEN THE System creates a Workflow Graph THEN THE System SHALL assign a unique workflow_id
5. WHEN THE System creates a Workflow Graph THEN THE System SHALL initialize learning state to OBSERVATION
6. WHEN THE System saves a Workflow Graph THEN THE System SHALL serialize it to JSON with all nodes, edges and metadata
### Requirement 8
**User Story:** En tant que développeur système, je veux implémenter les états d'apprentissage progressif (OBSERVATION, COACHING, AUTO_CANDIDATE, AUTO_CONFIRMÉ), afin de permettre au système d'apprendre graduellement.
#### Acceptance Criteria
1. WHEN THE System initializes a workflow THEN THE System SHALL set learning state to OBSERVATION
2. WHEN THE System has observed a workflow 5 times with similarity > 0.90 THEN THE System SHALL transition to COACHING state
3. WHEN THE System has assisted a workflow 10 times with success rate > 0.90 THEN THE System SHALL transition to AUTO_CANDIDATE state
4. WHEN THE System has executed a workflow 20 times in AUTO_CANDIDATE with success rate > 0.95 THEN THE System SHALL be eligible for AUTO_CONFIRMÉ state
5. WHEN THE System transitions learning state THEN THE System SHALL log the transition with reason and timestamp
6. WHEN THE System is in AUTO_CONFIRMÉ state and confidence drops below 0.90 THEN THE System SHALL rollback to COACHING state
### Requirement 9
**User Story:** En tant que développeur système, je veux matcher un ScreenState actuel contre les WorkflowNodes existants, afin de reconnaître dans quel état du workflow on se trouve.
#### Acceptance Criteria
1. WHEN THE System matches a ScreenState THEN THE System SHALL compute State Embedding for current screen
2. WHEN THE System matches a ScreenState THEN THE System SHALL search FAISS index for similar node prototypes
3. WHEN THE System matches a ScreenState THEN THE System SHALL validate window constraints for candidate nodes
4. WHEN THE System matches a ScreenState THEN THE System SHALL validate required text patterns for candidate nodes
5. WHEN THE System matches a ScreenState THEN THE System SHALL validate required UI elements for candidate nodes
6. WHEN THE System matches a ScreenState THEN THE System SHALL return best matching node with confidence score
7. WHEN THE System matches a ScreenState and no node matches above threshold THEN THE System SHALL return null match
### Requirement 10
**User Story:** En tant que développeur système, je veux exécuter les actions définies dans WorkflowEdges en trouvant les UIElements par rôle, afin d'automatiser le workflow de manière robuste.
#### Acceptance Criteria
1. WHEN THE System executes a WorkflowEdge THEN THE System SHALL find target UIElement by semantic role in current ScreenState
2. WHEN THE System executes a mouse_click action THEN THE System SHALL click on the center of the matched UIElement
3. WHEN THE System executes a text_input action THEN THE System SHALL type text into the matched UIElement
4. WHEN THE System executes a compound action THEN THE System SHALL execute all steps in sequence
5. WHEN THE System executes an action THEN THE System SHALL wait for post-conditions to be satisfied
6. WHEN THE System executes an action THEN THE System SHALL verify transition to expected target node
7. WHEN THE System executes an action and post-conditions fail THEN THE System SHALL log failure and rollback if possible
### Requirement 11
**User Story:** En tant que développeur système, je veux détecter automatiquement les patterns répétés dans les RawSessions, afin de construire les Workflow Graphs sans intervention manuelle.
#### Acceptance Criteria
1. WHEN THE System analyzes a RawSession THEN THE System SHALL group events by window context
2. WHEN THE System analyzes a RawSession THEN THE System SHALL create ScreenStates for all screenshots
3. WHEN THE System analyzes a RawSession THEN THE System SHALL compute State Embeddings for all ScreenStates
4. WHEN THE System analyzes a RawSession THEN THE System SHALL detect repeated sequences using embedding similarity
5. WHEN THE System detects a repeated sequence THEN THE System SHALL cluster similar ScreenStates into candidate nodes
6. WHEN THE System detects a repeated sequence THEN THE System SHALL identify transitions as candidate edges
7. WHEN THE System detects a repeated sequence with 3+ repetitions THEN THE System SHALL propose a Workflow Graph
### Requirement 12
**User Story:** En tant que développeur système, je veux persister tous les artefacts (ScreenStates, Embeddings, Workflow Graphs) de manière structurée, afin de pouvoir les recharger et les analyser.
#### Acceptance Criteria
1. WHEN THE System saves a ScreenState THEN THE System SHALL write JSON file with schema version
2. WHEN THE System saves embeddings THEN THE System SHALL write numpy arrays to .npy files
3. WHEN THE System saves embeddings THEN THE System SHALL add vectors to FAISS index
4. WHEN THE System saves a Workflow Graph THEN THE System SHALL write JSON file with all nodes and edges
5. WHEN THE System loads a Workflow Graph THEN THE System SHALL deserialize JSON and reconstruct graph structure
6. WHEN THE System loads embeddings THEN THE System SHALL load FAISS index and metadata mappings
7. WHEN THE System saves artifacts THEN THE System SHALL organize files by date and workflow_id
### Requirement 13
**User Story:** En tant que développeur système, je veux valider la qualité des State Embeddings, afin de m'assurer qu'ils discriminent bien les différents états.
#### Acceptance Criteria
1. WHEN THE System validates State Embeddings THEN THE System SHALL compute intra-node similarity (states of same node should be similar)
2. WHEN THE System validates State Embeddings THEN THE System SHALL compute inter-node similarity (states of different nodes should be dissimilar)
3. WHEN THE System validates State Embeddings THEN THE System SHALL compute embedding quality score as ratio of intra/inter similarity
4. WHEN THE System validates State Embeddings and quality score is below 0.70 THEN THE System SHALL log warning
5. WHEN THE System validates State Embeddings THEN THE System SHALL report discriminative power metric
### Requirement 14
**User Story:** En tant que développeur système, je veux gérer les erreurs de matching et d'exécution de manière robuste, afin que le système soit résilient aux changements d'UI.
#### Acceptance Criteria
1. WHEN THE System fails to match a ScreenState to any node THEN THE System SHALL log the unmatched state with screenshot
2. WHEN THE System fails to find a target UIElement by role THEN THE System SHALL try fallback strategies (visual similarity, position)
3. WHEN THE System fails to execute an action THEN THE System SHALL log the failure with context
4. WHEN THE System detects UI change (similarity drop) THEN THE System SHALL pause execution and notify user
5. WHEN THE System is in AUTO_CONFIRMÉ and confidence drops THEN THE System SHALL rollback to COACHING state
6. WHEN THE System encounters repeated failures on same edge THEN THE System SHALL mark edge as problematic
### Requirement 15
**User Story:** En tant que développeur système, je veux optimiser les performances du système, afin que le matching et l'exécution soient rapides (< 400ms).
#### Acceptance Criteria
1. WHEN THE System computes State Embedding THEN THE System SHALL complete in less than 100ms
2. WHEN THE System matches ScreenState against nodes THEN THE System SHALL complete FAISS search in less than 50ms
3. WHEN THE System detects UI elements THEN THE System SHALL complete detection in less than 200ms
4. WHEN THE System executes an action THEN THE System SHALL complete execution in less than 50ms
5. WHEN THE System processes a ScreenState end-to-end THEN THE System SHALL complete in less than 400ms total

555
.kiro/specs/workflow-graph-implementation/tasks.md Normal file
View File

@@ -0,0 +1,555 @@
# Implementation Plan - RPA Vision V3
## Vue d'Ensemble
Plan d'implémentation complet pour RPA Vision V3 avec architecture en 5 couches.
**Principe** : Implémentation incrémentale avec tests à chaque étape. Focus sur le RPA 100% Vision avec workflows sémantiques.
## État Actuel
- ✅ **Phase 1** : Modèles de base (structures créées)
- ⏳ **Phase 2** : Système d'embeddings (structures créées, embedders à implémenter)
- ✅ **Phase 3** : UI Detection avec VLM (COMPLÉTÉ - 22 Nov 2024)
- ⏳ **Phase 3.5** : Optimisation Asynchrone (à faire)
- ⏳ **Phase 4** : Construction de Workflow Graphs (à faire)
- ⏳ **Phase 5-9** : Exécution, Apprentissage, Robustesse, etc.
## Résumé des Phases
- **Phase 1**: Modèles de base ✅ COMPLÉTÉ
- **Phase 2**: Système d'embedding ⏳ À COMPLÉTER (embedders réels)
- **Phase 3**: UI Detection avec VLM ✅ COMPLÉTÉ (22 Nov 2024)
- **Phase 3.5**: Optimisation Asynchrone 🚀 PROCHAINE
- **Phase 4**: Construction de Workflow Graphs ⏳ EN ATTENTE
- **Phase 5**: Exécution et Apprentissage ⏳ EN ATTENTE
- **Phase 6-9**: Robustesse, Persistence, Optimisation ⏳ EN ATTENTE
---
## Tasks
- [ ] 1. Phase 1 : Fondations - Structures de Données
- Créer les classes de base pour toutes les couches
- Implémenter sérialisation/désérialisation JSON
- _Requirements: 1.4, 1.5, 2.6, 7.6, 12.1, 12.4, 12.5_
- [ ] 1.1 Créer modèle RawSession avec sérialisation JSON
- Implémenter classe `RawSession` dans `geniusia2/core/models/raw_session.py`
- Implémenter classes `Event` et `Screenshot`
- Implémenter méthodes `to_json()` et `from_json()`
- Valider schéma "rawsession_v1"
- _Requirements: 1.4, 1.5_
- [ ]* 1.2 Écrire tests unitaires pour RawSession
- Tester sérialisation/désérialisation
- Tester ajout d'événements et screenshots
- Tester validation de schéma
- **Property 1: RawSession Serialization Round Trip**
- **Validates: Requirements 1.4, 1.5**
- [ ] 1.3 Créer modèle ScreenState avec 4 niveaux
- Implémenter classe `ScreenState` dans `geniusia2/core/models/screen_state.py`
- Implémenter classes `RawLevel`, `PerceptionLevel`, `ContextLevel`
- Implémenter méthodes `to_json()` et `from_json()`
- _Requirements: 2.1, 2.2, 2.3, 2.4, 2.5, 2.6_
- [ ]* 1.4 Écrire tests unitaires pour ScreenState
- Tester création des 4 niveaux
- Tester sérialisation/désérialisation
- **Property 2: ScreenState Multi-Level Consistency**
- **Validates: Requirements 2.1, 2.2, 2.3, 2.4, 2.5**
- [ ] 1.5 Créer modèle UIElement avec embeddings duaux
- Implémenter classe `UIElement` dans `geniusia2/core/models/ui_element.py`
- Implémenter classes `UIElementEmbeddings`, `VisualFeatures`
- Implémenter méthodes `to_json()` et `from_json()`
- _Requirements: 3.7_
- [ ]* 1.6 Écrire tests unitaires pour UIElement
- Tester création avec tous les attributs
- Tester sérialisation/désérialisation
- **Property 3: UIElement Detection Confidence Bounds**
- **Validates: Requirements 3.6**
- [ ] 1.7 Créer modèle StateEmbedding
- Implémenter classe `StateEmbedding` dans `geniusia2/core/models/state_embedding.py`
- Implémenter méthode `get_vector()` pour charger .npy
- Implémenter méthode `compute_similarity()`
- _Requirements: 4.7, 4.8_
- [ ]* 1.8 Écrire tests unitaires pour StateEmbedding
- Tester chargement de vecteur
- Tester calcul de similarité
- **Property 4: State Embedding Normalization**
- **Property 5: State Embedding Similarity Symmetry**
- **Property 6: State Embedding Similarity Bounds**
- **Validates: Requirements 4.6, 4.7**
- [ ] 1.9 Créer modèles Workflow Graph (Node, Edge, Workflow)
- Implémenter classes dans `geniusia2/core/models/workflow_graph.py`
- Implémenter `WorkflowNode`, `WorkflowEdge`, `Workflow`
- Implémenter classes de support (ScreenTemplate, Action, etc.)
- Implémenter méthodes `to_json()` et `from_json()`
- _Requirements: 5.6, 6.7, 7.6_
- [ ]* 1.10 Écrire tests unitaires pour Workflow Graph
- Tester création de nodes et edges
- Tester sérialisation/désérialisation
- **Property 12: Workflow Graph Structural Validity**
- **Property 18: Workflow JSON Serialization Round Trip**
- **Validates: Requirements 7.2, 7.6, 12.4, 12.5**
- [ ] 2. Phase 2 : Système d'Embeddings et FAISS
- Implémenter fusion multi-modale
- Implémenter gestion FAISS
- Optimiser performances
- _Requirements: 4.1, 4.2, 4.3, 4.4, 4.5, 4.6, 4.8, 12.3, 12.6, 15.1, 15.2_
- [ ] 2.1 Implémenter FusionEngine pour fusion pondérée
- Créer classe `FusionEngine` dans `geniusia2/core/embedding/fusion_engine.py`
- Implémenter méthode `fuse()` avec fusion pondérée
- Implémenter normalisation des vecteurs
- Configurer poids par défaut (image: 0.5, text: 0.3, title: 0.1, ui: 0.1)
- _Requirements: 4.5, 4.6_
- [ ]* 2.2 Écrire tests unitaires pour FusionEngine
- Tester fusion pondérée
- Tester normalisation
- **Property 17: State Embedding Component Weights Sum**
- **Validates: Requirements 4.5**
- [ ] 2.3 Implémenter FAISSManager pour indexation
- Créer classe `FAISSManager` dans `geniusia2/core/embedding/faiss_manager.py`
- Implémenter méthode `add_embedding()`
- Implémenter méthode `search_similar()`
- Implémenter sauvegarde/chargement d'index
- Gérer metadata_store pour mappings
- _Requirements: 4.8, 12.3, 12.6_
- [ ]* 2.4 Écrire tests unitaires pour FAISSManager
- Tester ajout d'embeddings
- Tester recherche de similarité
- Tester sauvegarde/chargement
- **Property 11: FAISS Index Consistency**
- **Validates: Requirements 4.8, 12.3, 12.6**
- [ ] 2.5 Implémenter calculs de similarité
- Créer module `geniusia2/core/embedding/similarity.py`
- Implémenter similarité cosinus
- Implémenter distance euclidienne
- Implémenter normalisation L2
- _Requirements: 4.7_
- [ ]* 2.6 Écrire tests de performance pour embeddings
- Benchmarker temps de fusion (cible: <100ms)
- Benchmarker temps de recherche FAISS (cible: <50ms)
- **Property 19: Performance Constraint - State Embedding**
- **Validates: Requirements 15.1, 15.2**
- [ ] 2.7 Implémenter StateEmbeddingBuilder
- Créer classe pour construire State Embeddings complets
- Intégrer FusionEngine
- Calculer embeddings pour image, texte, titre, UI
- Sauvegarder vecteurs en .npy
- _Requirements: 4.1, 4.2, 4.3, 4.4, 4.5, 4.6_
- [ ]* 2.8 Écrire tests d'intégration pour StateEmbeddingBuilder
- Tester construction complète depuis ScreenState
- Tester sauvegarde de vecteurs
- Vérifier normalisation finale
- [ ] 3. Checkpoint - Vérifier que tous les tests passent
- Ensure all tests pass, ask the user if questions arise.
- [ ] 4. Phase 3 : Détection UI Sémantique
- Intégrer VLM pour détection
- Classifier types et rôles
- Générer embeddings duaux
- _Requirements: 3.1, 3.2, 3.3, 3.4, 3.5, 3.6, 3.7, 15.3_
- [ ] 4.1 Créer UIDetector avec intégration VLM
- Créer classe `UIDetector` dans `geniusia2/core/detection/ui_detector.py`
- Intégrer client VLM (Qwen 2.5-VL via Ollama)
- Implémenter détection de régions d'intérêt
- _Requirements: 3.1_
- [ ] 4.2 Implémenter classification de types UI
- Ajouter méthode `classify_type()` dans UIDetector
- Supporter types: button, text_input, checkbox, radio, dropdown, tab, link, icon, table_row, menu_item
- Utiliser VLM pour classification
- _Requirements: 3.2_
- [ ] 4.3 Implémenter classification de rôles sémantiques
- Ajouter méthode `classify_role()` dans UIDetector
- Supporter rôles: primary_action, cancel, submit, form_input, search_field, etc.
- Utiliser contexte visuel et textuel
- _Requirements: 3.3_
- [ ] 4.4 Implémenter extraction de features visuelles
- Ajouter méthode `extract_visual_features()`
- Extraire couleur dominante, forme, taille
- Détecter présence d'icônes
- _Requirements: 3.4_
- [ ] 4.5 Implémenter génération d'embeddings duaux
- Intégrer OpenCLIP pour embeddings
- Générer embedding image (crop de l'élément)
- Générer embedding texte (label détecté)
- Sauvegarder embeddings en .npy
- _Requirements: 3.5_
- [ ] 4.6 Implémenter calcul de confiance de détection
- Combiner confiance VLM + confiance classification
- Filtrer éléments sous seuil (0.7)
- _Requirements: 3.6_
- [ ]* 4.7 Écrire tests unitaires pour UIDetector
- Tester détection avec screenshots de test
- Tester classification de types et rôles
- Tester génération d'embeddings
- **Property 13: UIElement Role Uniqueness Per Type**
- **Validates: Requirements 3.3**
- [ ]* 4.8 Écrire tests de performance pour détection UI
- Benchmarker temps de détection (cible: <200ms)
- Tester avec screenshots de différentes tailles
- **Validates: Requirements 15.3**
- [ ] 5. Phase 4 : Construction et Matching de Workflow Graphs
- Construire graphes depuis sessions
- Matcher ScreenStates contre nodes
- Détecter patterns répétés
- _Requirements: 5.1, 5.2, 5.3, 5.4, 5.5, 9.1, 9.2, 9.3, 9.4, 9.5, 9.6, 9.7, 11.1, 11.2, 11.3, 11.4, 11.5, 11.6, 11.7_
- [ ] 5.1 Implémenter GraphBuilder pour construction automatique
- Créer classe `GraphBuilder` dans `geniusia2/core/graph/graph_builder.py`
- Implémenter méthode `build_from_session()`
- Créer ScreenStates depuis RawSession
- Calculer State Embeddings pour tous les états
- _Requirements: 11.1, 11.2, 11.3_
- [ ] 5.2 Implémenter détection de patterns répétés
- Ajouter méthode `_detect_patterns()` dans GraphBuilder
- Utiliser clustering sur embeddings (DBSCAN ou K-means)
- Identifier transitions récurrentes entre clusters
- Détecter séquences avec 3+ répétitions
- _Requirements: 11.4, 11.5, 11.6, 11.7_
- [ ]* 5.3 Écrire tests pour détection de patterns
- Tester avec sessions simulées
- Vérifier détection de répétitions
- **Property 16: Pattern Detection Minimum Repetitions**
- **Validates: Requirements 11.7**
- [ ] 5.4 Implémenter construction de WorkflowNodes depuis patterns
- Ajouter méthode `_build_nodes()` dans GraphBuilder
- Créer ScreenTemplate depuis cluster d'états
- Calculer embedding prototype (moyenne des embeddings)
- Extraire contraintes de fenêtre et texte requis
- Identifier éléments UI requis
- _Requirements: 5.1, 5.2, 5.3, 5.4, 5.5_
- [ ]* 5.5 Écrire tests pour construction de nodes
- Tester création de templates
- Tester calcul de prototypes
- **Property 14: Embedding Prototype Sample Count**
- **Validates: Requirements 5.4**
- [ ] 5.6 Implémenter construction de WorkflowEdges depuis transitions
- Ajouter méthode `_build_edges()` dans GraphBuilder
- Identifier actions entre états (depuis événements RawSession)
- Créer TargetSpec avec rôles sémantiques
- Définir pre-conditions et post-conditions
- _Requirements: 6.1, 6.2, 6.3, 6.4, 6.5, 6.6_
- [ ]* 5.7 Écrire tests pour construction d'edges
- Tester identification d'actions
- Tester création de TargetSpec
- Vérifier contraintes
- [ ] 5.8 Implémenter NodeMatcher pour matching en temps réel
- Créer classe `NodeMatcher` dans `geniusia2/core/graph/node_matcher.py`
- Implémenter méthode `match()`
- Calculer State Embedding du ScreenState actuel
- Chercher dans FAISS les prototypes similaires
- Valider contraintes (fenêtre, texte, UI)
- _Requirements: 9.1, 9.2, 9.3, 9.4, 9.5, 9.6, 9.7_
- [ ]* 5.9 Écrire tests pour NodeMatcher
- Tester matching avec différents seuils
- Tester validation de contraintes
- Tester cas où aucun node ne match
- **Property 7: WorkflowNode Matching Consistency**
- **Validates: Requirements 9.1, 9.2, 9.3, 9.4, 9.5, 9.6**
- [ ] 5.10 Implémenter méthode WorkflowNode.matches()
- Ajouter logique de matching dans WorkflowNode
- Vérifier contraintes de fenêtre
- Vérifier texte requis présent
- Vérifier éléments UI requis présents
- Vérifier similarité embedding > seuil
- Retourner (match: bool, confidence: float)
- _Requirements: 5.1, 5.2, 5.3, 5.4, 5.5_
- [ ]* 5.11 Écrire tests d'intégration pour workflow complet
- Tester construction depuis session → matching
- Vérifier graphe construit correctement
- Vérifier matching fonctionne sur nouveaux états
- [ ] 6. Checkpoint - Vérifier que tous les tests passent
- Ensure all tests pass, ask the user if questions arise.
- [ ] 7. Phase 5 : Exécution d'Actions et Apprentissage Progressif
- Exécuter actions par rôle sémantique
- Gérer états d'apprentissage
- Implémenter transitions automatiques
- _Requirements: 8.1, 8.2, 8.3, 8.4, 8.5, 8.6, 10.1, 10.2, 10.3, 10.4, 10.5, 10.6, 10.7, 15.4_
- [ ] 7.1 Implémenter ActionExecutor pour exécution d'actions
- Créer classe `ActionExecutor` dans `geniusia2/core/graph/action_executor.py`
- Implémenter méthode `execute_edge()`
- Vérifier pre-conditions avant exécution
- _Requirements: 10.5_
- [ ] 7.2 Implémenter recherche d'éléments par rôle sémantique
- Ajouter méthode `_find_target_element()` dans ActionExecutor
- Chercher UIElements par rôle dans ScreenState
- Appliquer selection_policy (first, last, by_similarity)
- Implémenter fallback strategies
- _Requirements: 10.1_
- [ ] 7.3 Implémenter exécution d'actions mouse_click
- Ajouter méthode `_execute_click()` dans ActionExecutor
- Cliquer au centre de l'UIElement trouvé
- Appliquer click_offset si configuré
- Attendre wait_after_ms
- _Requirements: 10.2_
- [ ] 7.4 Implémenter exécution d'actions text_input
- Ajouter méthode `_execute_text_input()` dans ActionExecutor
- Taper texte dans l'UIElement trouvé
- Gérer caractères spéciaux
- _Requirements: 10.3_
- [ ] 7.5 Implémenter exécution d'actions compound
- Ajouter méthode `_execute_compound()` dans ActionExecutor
- Exécuter séquence d'actions
- Gérer repeat policies (all, until_success)
- _Requirements: 10.4_
- [ ] 7.6 Implémenter vérification de post-conditions
- Ajouter méthode `_wait_for_postconditions()` dans ActionExecutor
- Attendre changement de fenêtre si requis
- Attendre nouveaux éléments UI si requis
- Vérifier transition vers node attendu
- Timeout si post-conditions non satisfaites
- _Requirements: 10.6_
- [ ]* 7.7 Écrire tests unitaires pour ActionExecutor
- Tester recherche d'éléments par rôle
- Tester exécution de chaque type d'action
- Tester vérification de post-conditions
- **Property 8: WorkflowEdge Pre-Condition Validation**
- **Property 15: Action Execution Timeout**
- **Validates: Requirements 10.5, 10.6**
- [ ]* 7.8 Écrire tests de performance pour exécution
- Benchmarker temps d'exécution (cible: <50ms)
- **Validates: Requirements 15.4**
- [ ] 7.9 Implémenter LearningManager pour états d'apprentissage
- Créer classe `LearningManager` dans `geniusia2/core/graph/learning_manager.py`
- Gérer dictionnaire de workflows
- Implémenter méthode `update_workflow_stats()`
- _Requirements: 8.5_
- [ ] 7.10 Implémenter transitions d'états d'apprentissage
- Ajouter méthode `_check_state_transition()` dans LearningManager
- Implémenter `_can_transition_to_coaching()` (5 observations, similarité >0.90)
- Implémenter `_can_transition_to_auto_candidate()` (10 assists, succès >0.90)
- Implémenter `_can_transition_to_auto_confirmed()` (20 exécutions, succès >0.95)
- Logger toutes les transitions avec raison
- _Requirements: 8.1, 8.2, 8.3, 8.4, 8.5_
- [ ] 7.11 Implémenter rollback automatique
- Ajouter méthode `_should_rollback()` dans LearningManager
- Détecter confiance < 0.90 en mode AUTO_CONFIRMÉ
- Rétrograder vers COACHING
- Logger le rollback
- _Requirements: 8.6_
- [ ]* 7.12 Écrire tests pour LearningManager
- Tester transitions d'états
- Tester calcul de métriques
- Tester rollback
- **Property 9: Learning State Monotonic Progression**
- **Property 10: Learning State Rollback Condition**
- **Validates: Requirements 8.1, 8.2, 8.3, 8.4, 8.6**
- [ ]* 7.13 Écrire tests d'intégration pour apprentissage complet
- Simuler 5 observations → COACHING
- Simuler 10 assists → AUTO_CANDIDATE
- Simuler 20 exécutions → AUTO_CONFIRMÉ
- Simuler baisse de confiance → rollback
- [ ] 8. Checkpoint - Vérifier que tous les tests passent
- Ensure all tests pass, ask the user if questions arise.
- [ ] 9. Phase 6 : Gestion des Erreurs et Robustesse
- Gérer échecs de matching
- Gérer échecs de détection
- Gérer violations de post-conditions
- Détecter changements d'UI
- _Requirements: 14.1, 14.2, 14.3, 14.4, 14.5, 14.6_
- [ ] 9.1 Implémenter gestion d'échecs de matching
- Ajouter logging détaillé dans NodeMatcher
- Logger ScreenState non matché avec screenshot
- Calculer similarité avec tous les nodes
- Suggérer mise à jour ou création de node
- _Requirements: 14.1_
- [ ] 9.2 Implémenter stratégies de fallback pour détection UI
- Ajouter fallback par visual similarity dans ActionExecutor
- Ajouter fallback par position approximative
- Logger tentatives de fallback
- _Requirements: 14.2_
- [ ] 9.3 Implémenter gestion de violations de post-conditions
- Logger violations avec détails (attendu vs réel)
- Attendre timeout configuré
- Marquer exécution comme échec si timeout
- Incrémenter compteur d'échecs pour edge
- Marquer edge comme problématique si échecs répétés (>3)
- _Requirements: 14.3_
- [ ] 9.4 Implémenter détection de changements d'UI
- Ajouter méthode `detect_ui_change()` dans NodeMatcher
- Comparer similarité actuelle vs prototype
- Détecter changement si similarité < 0.70
- Capturer screenshot pour analyse
- Mettre en pause exécution automatique
- Notifier utilisateur
- _Requirements: 14.4_
- [ ] 9.5 Implémenter système de rollback
- Ajouter méthode `rollback()` dans ActionExecutor
- Stocker historique des 3 dernières actions
- Implémenter inverse pour chaque type d'action
- Logger tentatives de rollback
- _Requirements: 14.5_
- [ ]* 9.6 Écrire tests pour gestion d'erreurs
- Tester échec de matching
- Tester échec de détection UI
- Tester violation de post-conditions
- Tester détection de changement UI
- Tester rollback
- [ ] 10. Phase 7 : Persistence et Storage
- Implémenter sauvegarde structurée
- Implémenter chargement avec validation
- Organiser fichiers par date et workflow
- _Requirements: 12.1, 12.2, 12.3, 12.4, 12.5, 12.6, 12.7_
- [ ] 10.1 Implémenter StorageManager pour gestion de fichiers
- Créer classe `StorageManager` dans `geniusia2/core/persistence/storage_manager.py`
- Implémenter méthode `save_raw_session()`
- Implémenter méthode `save_screen_state()`
- Implémenter méthode `save_workflow()`
- Organiser par date (YYYY-MM-DD)
- _Requirements: 12.1, 12.2, 12.4, 12.7_
- [ ] 10.2 Implémenter sauvegarde d'embeddings
- Ajouter méthode `save_embedding()` dans StorageManager
- Sauvegarder vecteurs en .npy
- Ajouter à FAISS index
- Sauvegarder métadonnées
- _Requirements: 12.2, 12.3_
- [ ] 10.3 Implémenter chargement avec validation
- Ajouter méthode `load_workflow()` dans StorageManager
- Valider schéma JSON
- Charger FAISS index
- Charger métadonnées
- Reconstruire objets Python
- _Requirements: 12.5, 12.6_
- [ ]* 10.4 Écrire tests pour persistence
- Tester sauvegarde/chargement de tous les types
- Tester organisation de fichiers
- Tester validation de schémas
- [ ] 11. Phase 8 : Optimisation et Performance
- Optimiser embeddings (batching, caching)
- Optimiser FAISS (IVF index)
- Optimiser détection UI (ROI)
- Mesurer et valider performances
- _Requirements: 15.1, 15.2, 15.3, 15.4, 15.5_
- [ ] 11.1 Implémenter batch processing pour embeddings
- Ajouter méthode `compute_embeddings_batch()` dans FusionEngine
- Traiter multiples images en parallèle
- Optimiser utilisation GPU si disponible
- [ ] 11.2 Implémenter caching d'embeddings
- Ajouter cache LRU pour prototypes
- Mettre en cache derniers State Embeddings
- Invalider cache intelligemment
- [ ] 11.3 Optimiser FAISS avec index IVF
- Migrer vers index IVF pour >10k embeddings
- Optimiser périodiquement l'index
- Utiliser GPU si disponible
- [ ] 11.4 Optimiser détection UI avec ROI
- Limiter résolution des screenshots (max 1920x1080)
- Détecter régions d'intérêt avant traitement complet
- Mettre en cache résultats pour frames similaires
- [ ]* 11.5 Écrire tests de performance complets
- Benchmarker toutes les opérations
- Valider contraintes de temps
- **Property 19: Performance Constraint - State Embedding**
- **Property 20: Performance Constraint - End-to-End**
- **Validates: Requirements 15.1, 15.2, 15.3, 15.4, 15.5**
- [ ] 12. Checkpoint Final - Vérifier que tous les tests passent
- Ensure all tests pass, ask the user if questions arise.
- [ ] 13. Phase 9 : Tests End-to-End et Documentation
- Tests de bout en bout complets
- Documentation utilisateur
- Guide de déploiement
- [ ] 13.1 Créer tests end-to-end pour workflow complet
- Tester capture → construction → matching → exécution
- Tester apprentissage progressif complet
- Tester robustesse aux changements UI
- Tester multi-workflows
- [ ]* 13.2 Écrire tests de validation de qualité
- Tester qualité des embeddings
- **Property 13: UIElement Role Uniqueness Per Type**
- **Validates: Requirements 13.1, 13.2, 13.3, 13.4, 13.5**
- [ ] 13.3 Créer documentation utilisateur
- Guide de démarrage rapide
- Guide d'utilisation des 5 couches
- Exemples de workflows
- FAQ et troubleshooting
- [ ] 13.4 Créer guide de déploiement
- Instructions d'installation
- Configuration requise
- Configuration des modèles
- Optimisation de production