# Cahier des Charges - AISSIA (AI Smart Schedule & Interactive Assistant)

**Version:** 0.4 - Architecture Hybride Proposée
**Date:** 27 octobre 2025
**Auteur:** Alexis Trouvé

---

## 1. Contexte et Problématique

### 1.1 Besoin Utilisateur
Difficulté majeure dans la gestion du temps et des priorités, caractérisée par :
- **Hyperfocus** : Incapacité à stopper une tâche une fois démarrée (travail ou jeu vidéo)
- **Absence de limites claires** : Continuer jusqu'à épuisement physique ("body tell me I can't")
- **Multi-tâches impossibles** : Difficulté à gérer 2-3 activités différentes dans une journée
- **Régulation de l'attention défaillante** : Besoin d'un système externe pour gérer les transitions

### 1.2 Solution Proposée
Assistant personnel intelligent et proactif qui :
- Pense le planning en arrière-plan
- Intervient de manière proactive (pas seulement réactif)
- S'adapte aux patterns comportementaux de l'utilisateur
- Force les transitions quand nécessaire

---

## 2. Objectifs du Projet

### 2.1 Objectifs Fonctionnels
1. **Planning Intelligent** : IA qui organise automatiquement les tâches selon priorités et contraintes
2. **Assistant Proactif** : Détection d'hyperfocus et intervention automatique
3. **Tracking Automatique** : Suivi du temps passé sur chaque activité
4. **Interaction Naturelle** : Dialogue avec l'IA pour ajuster le planning en temps réel
5. **Notifications Intelligentes** : Rappels adaptatifs basés sur le contexte

### 2.2 Objectifs Techniques
- **Dev Windows-first** : Développement et debug 100% sur Windows avec WarFactory engine
- **Déploiement flexible** : Mode local (DLL) OU mode cloud (WASM + PWA) selon besoin
- **Hot-reload dev** : 0.4ms iteration en mode local (WarFactory)
- **Cross-platform automatique** : Deploy sur tous OS via Docker/WASM (sans effort dev)
- **Mobile optionnel** : PWA installable (Phase 2+, pas obligatoire MVP)
- **Offline-first** : Fonctionne en local (SQLite) ou avec sync cloud optionnel
- **Performance** : Native en local (DLL), quasi-native en WASM (~2x plus lent acceptable)
- **Privacy** : Mode local = données jamais uploadées, mode cloud = processing client-side
- **Coûts optimisés** : $0 en mode local, $3-5/mois en mode cloud (70% processing client)

### 2.3 Objectifs Business
- **Usage personnel** : Version pour usage propre en priorité
- **Commercialisation** : Potentiel de monétisation futur (Freemium)
- **Itérations courtes** : Cycles de développement de 1-2 semaines
- **Versions fonctionnelles** : Chaque itération doit produire une version utilisable

---

## 3. Fonctionnalités

### 3.1 MVP - Phase 1 (Semaines 1-2)

#### Gestion des Tâches
- ✅ Création/édition/suppression de tâches
- ✅ Priorités (Haute/Moyenne/Basse)
- ✅ Durée estimée
- ✅ Deadlines optionnelles
- ✅ Tags/catégories

#### Tracking du Temps
- ✅ Timer manuel (start/stop)
- ✅ Historique du temps passé par tâche
- ✅ Vue journalière/hebdomadaire

#### IA Basique
- ✅ Suggestions de planning pour la journée
- ✅ Réorganisation des tâches selon priorités
- ✅ Estimation durée réaliste basée sur historique

#### Notifications
- ✅ Rappels de début de tâche
- ✅ Alertes de fin de tâche planifiée
- ✅ Notifications push sur tous les appareils

#### Authentification
- ✅ Inscription/connexion email/password
- ✅ Synchronisation multi-appareils

### 3.2 Phase 2 - IA Proactive (Semaines 3-4)

#### Détection d'Hyperfocus
- ⏳ Analyse du temps passé vs temps planifié
- ⏳ Détection de patterns anormaux (>2h sans pause)
- ⏳ Alertes progressives (douce → insistante → forcée)

#### Assistant Conversationnel
- ⏳ Chat avec l'IA pour ajuster le planning
- ⏳ Commandes vocales (optionnel)
- ⏳ Suggestions contextuelles ("Tu devrais faire une pause")

#### Apprentissage des Patterns
- ⏳ Analyse des heures productives
- ⏳ Détection des activités "dangereuses" (jeux vidéo, etc.)
- ⏳ Adaptation du planning selon l'état de fatigue

#### Interventions Proactives
- ⏳ Blocage d'applications (optionnel, sur demande)
- ⏳ Rappels de breaks forcés
- ⏳ Réorganisation automatique si dérive détectée

### 3.3 Phase 3 - Fonctionnalités Avancées (Semaines 5+)

#### Intelligence Contextuelle
- 🔮 Détection automatique d'activité (via tracking d'apps)
- 🔮 Prédiction des risques d'hyperfocus
- 🔮 Suggestions de planning optimal selon l'énergie

#### Intégrations
- 🔮 Calendrier (Google, Outlook)
- 🔮 Outils de productivité (Notion, Todoist)
- 🔮 Tracking d'activité (RescueTime, ActivityWatch)

#### Gamification (Optionnel)
- 🔮 Système de points/récompenses
- 🔮 Streaks (jours consécutifs avec planning respecté)
- 🔮 Achievements

#### Analytics
- 🔮 Rapports hebdomadaires/mensuels
- 🔮 Visualisations de productivité
- 🔮 Insights IA sur les habitudes

---

## 4. Architecture Technique

### 4.1 Proposition Architecturale : Architecture Hybride WarFactory + WASM

**PROPOSITION ARCHITECTURALE** : AISSIA pourrait réutiliser l'architecture modulaire WarFactory avec compilation multi-target optionnelle (DLL/SO/WASM).

**⚠️ IMPORTANT - Phases d'implémentation :**
- **Phase 1 (local_dev) = OBLIGATOIRE** : Cible principale MVP avec WarFactory DLL Windows uniquement
- **Phase 2 (POC WASM) = VALIDATION** : Tester faisabilité avant engagement
- **Phase 3 (production_pwa) = CONDITIONNELLE** : Seulement si Phase 2 validée ET besoin justifié

**Concept Révolutionnaire : Meilleur des Deux Mondes**

```
MÊME code C++ (IModule WarFactory)
    ↓ CMake multi-target
├─ monitoring.dll  (Dev Windows local + Hot-reload 0.4ms)
├─ monitoring.so   (Serveur Linux Docker - Phase 3)
└─ monitoring.wasm (Client PWA browser - Phase 3)

UN SEUL CODE, TROIS DÉPLOIEMENTS !
```

**Architecture Hybride Proposée (À valider par POC) :**
- 🎯 **Réutilisation WarFactory** : Interfaces IModule/IEngine/IIO/ITaskScheduler inchangées (validé)
- 🎯 **Développement 100% Windows** : Visual Studio 2022, DLL, ImGui, hot-reload 0.4ms (validé)
- ⚠️ **Modules C++ écrits UNE FOIS** : Compilés en DLL (dev), SO (serveur), WASM (browser) (hypothétique - à tester)
- ⚠️ **Déploiement flexible** : gameconfig.json bascule entre mode `local_dev` et `production_pwa` (hypothétique)
- ✅ **MVP = Mode Local OBLIGATOIRE** : aissia-core.exe + DLL + ImGui + SQLite ($0 coût)
- ⚠️ **Production optionnelle CONDITIONNELLE** : React PWA + WASM client + Docker serveur ($3-5/mois) - SI Phase 2 validée
- ⚠️ **Cross-platform automatique** : Docker + WASM = tourne partout sans effort (hypothétique - complexité à évaluer)
- ⚠️ **Mobile optionnel** : PWA installable (Phase 3+, SEULEMENT si besoin validé)

**Raisons de cette proposition :**
- ✅ **Réutilisation code existant** : Économie 3-4 semaines dev (WarFactory validé)
- ✅ **Hot-reload ultra-rapide** : 0.4ms en mode local_dev (DLL validé)
- ✅ **Types stricts C++** : Pas de "wildcode", headers et interfaces bien définis (validé)
- ✅ **Modularité** : Chaque fonctionnalité = module isolé (200-300 lignes, validé WarFactory)
- ✅ **Évolution progressive** : Commencer local ($0), décider cloud plus tard (stratégie validée)
- ⚠️ **Performance maximale** : Native en local (validé), quasi-native en WASM (hypothétique - à benchmarker)
- ✅ **Développement parallèle** : Multiples modules développés simultanément (validé WarFactory)
- ✅ **Coûts minimaux Phase 1** : $0 en MVP garanti
- ⚠️ **Pipeline flexible hypothétique** : Un seul codebase, multiples déploiements (complexité à évaluer)

### 4.2 Modes de Déploiement

**AISSIA propose DEUX modes de déploiement distincts, potentiellement sélectionnables via `gameconfig.json` :**

**⚠️ Clarification priorités :**
- **Mode 1 (local_dev) = OBLIGATOIRE** : Cible MVP, sera implémenté en Phase 1
- **Mode 2 (production_pwa) = OPTIONNEL** : Sera considéré SEULEMENT si Phase 2 (POC WASM) validée

#### Mode 1 : `local_dev` (MVP - Phase 1 OBLIGATOIRE)

**Architecture :**
```
┌─────────────────────────────────────┐
│  Windows PC                         │
│  ┌───────────────────────────────┐  │
│  │ aissia-core.exe               │  │
│  │ (WarFactory Engine)           │  │
│  │  ├─ IEngine (DebugEngine)     │  │
│  │  ├─ IModuleSystem (Sequential)│  │
│  │  └─ IIO (IntraIO)             │  │
│  └───────────────────────────────┘  │
│  ┌───────────────────────────────┐  │
│  │ Modules DLL                   │  │
│  │  ├─ monitoring.dll            │  │
│  │  ├─ scheduler.dll             │  │
│  │  ├─ ai.dll                    │  │
│  │  ├─ voice.dll                 │  │
│  │  ├─ storage.dll               │  │
│  │  └─ ui-imgui.dll              │  │
│  └───────────────────────────────┘  │
│  SQLite local (aissia.db)          │
└─────────────────────────────────────┘
```

**Caractéristiques :**
- ✅ **Hot-reload** : 0.4ms (750,000x plus rapide que rebuild complet)
- ✅ **UI** : Dear ImGui (C++, intégré WarFactory)
- ✅ **Storage** : SQLite local (aissia.db)
- ✅ **Coût** : $0 (tout local)
- ✅ **Privacy** : Données jamais uploadées (sauf appels Claude API)
- ✅ **Performance** : Native C++ (pas de WASM overhead)
- ✅ **Development** : Visual Studio 2022, debugging natif

**Utilisation :**
```json
// gameconfig.json
{
  "active_mode": "local_dev"
}
```

---

#### Mode 2 : `production_pwa` (Phase 3 - CONDITIONNEL, après validation Phase 2)

**Architecture :**
```
┌────────────────────────┐    ┌───────────────────────────────┐
│ CLIENT (PWA - Vercel)  │    │ SERVEUR (fly.io)              │
│ ┌────────────────────┐ │    │ ┌───────────────────────────┐ │
│ │ React + TypeScript │ │    │ │ Docker Linux              │ │
│ │ - Dashboard UI     │ │    │ │ Backend C++               │ │
│ │ - Task management  │ │    │ │  ├─ auth.so               │ │
│ └────────────────────┘ │    │ │  ├─ sync.so               │ │
│ ┌────────────────────┐ │    │ │  ├─ ai-proxy.so           │ │
│ │ WASM Modules       │ │    │ │  └─ monitoring.so         │ │
│ │  ├─ scheduler.wasm │ │    │ │ PostgreSQL                │ │
│ │  ├─ voice.wasm     │ │    │ └───────────────────────────┘ │
│ │  └─ storage.wasm   │ │    │ Port: 8080 (WebSocket)        │
│ └────────────────────┘ │    └───────────────────────────────┘
│ IndexedDB (cache)      │              ▲
│ Service Worker         │              │ WebSocket
└────────┬───────────────┘              │
         │                              │
         └──────────────────────────────┘
```

**Caractéristiques :**
- ✅ **UI** : React moderne + Tailwind CSS
- ✅ **Storage** : Hybrid (IndexedDB client + PostgreSQL serveur)
- ✅ **Coût** : $3-5/mois (fly.io + Vercel gratuit)
- ✅ **Mobile** : PWA installable iOS/Android
- ✅ **Scalable** : 70% processing client = coûts serveur minimaux
- ✅ **Cross-platform** : Fonctionne sur tous devices
- ⚠️ **Performance** : WASM ~2x plus lent que C++ natif (acceptable)

**Utilisation :**
```json
// gameconfig.json
{
  "active_mode": "production_pwa"
}
```

---

### 4.3 Stack Technologique Détaillée

#### Développement (Windows - Les Deux Modes)
- **IDE** : Visual Studio 2022 / VSCode
- **Compilateur** :
  - MSVC (Windows DLL)
  - GCC/Clang (Linux SO via Docker)
  - Emscripten (WASM browser)
- **Build System** : CMake (multi-target)
- **Containerization** : Docker Desktop (builds Linux SO)
- **Version Control** : Git + GitHub
- **CI/CD** : GitHub Actions

#### Mode `local_dev` - Modules C++ (DLL)
- **Core Engine** : WarFactory (aissia-core.exe)
  - IEngine (DebugEngine)
  - IModuleSystem (SequentialModuleSystem)
  - IIO (IntraIO pour communication locale)
  - ICoordinationModule (charge gameconfig.json)
- **Modules DLL** :
  - `monitoring.dll` : Win32 API tracking apps (GetForegroundWindow)
  - `scheduler.dll` : Algorithmes planning, détection procrastination
  - `ai.dll` : Claude Haiku API integration
  - `voice.dll` : SAPI TTS (Windows) + Whisper.cpp STT
  - `storage.dll` : SQLite local (aissia.db)
  - `ui-imgui.dll` : Interface ImGui
- **Base de données** : SQLite local (aissia.db)
- **Coût** : $0 (tout local, sauf appels Claude API $10-20/mois)

#### Mode `production_pwa` - Backend Serveur (SO)
- **Runtime** : Docker Linux container (Alpine ou Ubuntu)
- **Langage** : C++20
- **Modules Serveur (SO)** :
  - `auth.so` : Authentification JWT
  - `sync.so` : Synchronisation données PostgreSQL
  - `ai-proxy.so` : Proxy sécurisé pour Claude API (cache API key)
  - `monitoring.so` : Tracking apps (optionnel, serveur dédié)
  - `websocket-server.so` : API WebSocket pour clients PWA
- **Base de données** : PostgreSQL (fly.io managed)
- **Déploiement** : fly.io ($3-5/mois)

#### Mode `production_pwa` - Frontend Client (WASM)
- **Framework** : React 18 + TypeScript
- **Build** : Vite (hot-reload ultra-rapide)
- **UI Library** : Tailwind CSS + shadcn/ui
- **State Management** : Zustand ou Jotai (léger)
- **Modules Client (WASM)** :
  - `scheduler.wasm` : Algorithmes de planning (client-side)
  - `voice.wasm` : TTS/STT via Web Speech API
  - `storage.wasm` : Cache local IndexedDB
- **Offline** : Service Workers + IndexedDB
- **Notifications** : Web Push API
- **Déploiement** : Vercel (gratuit)

---

### 4.4 Modules C++ Partagés (Un Code, Trois Targets)

**Concept Clé** : Chaque module C++ implémente `IModule` de WarFactory et compile en 3 targets :

```cpp
// modules/scheduler/src/SchedulerModule.cpp
// MÊME CODE pour DLL/SO/WASM !

class SchedulerModule : public IModule {
public:
    json process(const json& input) override {
        // Logique pure (200-300 lignes)
        if (IsProcrastinating(input)) {
            return {
                {"event", "intervention_needed"},
                {"urgency", "high"}
            };
        }
        return {{"status", "ok"}};
    }

    void setConfiguration(const IDataNode& config,
                         IIO* io,
                         ITaskScheduler* scheduler) override {
        m_io = io;
        m_io->subscribe("task_changed", [this](const json& e) {
            process(e);
        });
    }

    json getHealthStatus() override {
        return {{"status", "healthy"}};
    }

    void shutdown() override { /* cleanup */ }

private:
    IIO* m_io = nullptr;
};

// ======== EXPORTS MULTI-TARGET ========

#ifdef _WIN32
// Export DLL Windows (dev local)
extern "C" __declspec(dllexport)
IModule* CreateModule() {
    return new SchedulerModule();
}
#endif

#ifdef __linux__
// Export SO Linux (serveur Docker)
extern "C"
IModule* CreateModule() {
    return new SchedulerModule();
}
#endif

#ifdef __EMSCRIPTEN__
// Export WASM (client browser)
#include <emscripten.h>
extern "C" {
    EMSCRIPTEN_KEEPALIVE
    const char* ProcessScheduler(const char* inputJson) {
        static SchedulerModule module;
        json input = json::parse(inputJson);
        json result = module.process(input);
        static std::string output = result.dump();
        return output.c_str();
    }
}
#endif
```

**Compilation :**
```cmake
# modules/scheduler/CMakeLists.txt (extrait)
# Target 1: DLL (Windows)
add_library(scheduler MODULE src/SchedulerModule.cpp)
set_target_properties(scheduler PROPERTIES SUFFIX ".dll")

# Target 2: SO (Linux)
add_library(scheduler MODULE src/SchedulerModule.cpp)
set_target_properties(scheduler PROPERTIES SUFFIX ".so")

# Target 3: WASM (Browser)
add_executable(scheduler src/SchedulerModule.cpp)
set_target_properties(scheduler PROPERTIES SUFFIX ".wasm")
target_link_options(scheduler PRIVATE -s WASM=1)
```

**Build Script :**
```powershell
# scripts/build-all.ps1
# Build DLL (dev Windows)
cmake -B build-windows -G "Visual Studio 17 2022"
cmake --build build-windows --config Release

# Build SO (serveur Linux via Docker)
docker build -t aissia-backend -f docker/Dockerfile.backend .

# Build WASM (client browser via Emscripten)
emcmake cmake -B build-wasm
emmake make -C build-wasm
```

**Résultat :**
```
build-windows/modules/scheduler.dll   (Dev local)
build-linux/modules/scheduler.so      (Serveur Docker)
build-wasm/modules/scheduler.wasm     (Client PWA)
```

#### Communication Client-Serveur
- **Protocole** : WebSocket (temps réel) + REST API (fallback)
- **Format** : JSON pour messages
- **Events Pub/Sub** :
  - Client → Serveur : `task_created`, `user_action`, `sync_request`
  - Serveur → Client : `ai_suggestion`, `sync_complete`, `notification`
- **Authentification** : JWT tokens (localStorage client)
- **Sécurité** : HTTPS/WSS obligatoire, CORS configuré

---

### 4.5 Configuration gameconfig.json (Unifié)

**Un seul fichier de configuration bascule entre les deux modes :**

```json
{
  "deployment_modes": {
    "local_dev": {
      "enabled": true,
      "description": "Dev Windows local avec hot-reload WarFactory",
      "modules": [
        {"name": "MonitoringModule", "type": "dll", "execution": "local"},
        {"name": "SchedulerModule", "type": "dll", "execution": "local"},
        {"name": "AIModule", "type": "dll", "execution": "local"},
        {"name": "VoiceModule", "type": "dll", "execution": "local"},
        {"name": "StorageModule", "type": "dll", "execution": "local"},
        {"name": "UIModule", "type": "dll", "execution": "local"}
      ],
      "io": "IntraIO",
      "engine": "DebugEngine",
      "ui": "ImGui",
      "storage": "SQLite",
      "cost": "$0"
    },

    "production_pwa": {
      "enabled": false,
      "description": "PWA React + WASM client + Serveur Docker",
      "client_modules_wasm": [
        {"name": "SchedulerModule", "file": "scheduler.wasm"},
        {"name": "VoiceModule", "file": "voice.wasm"},
        {"name": "StorageModule", "file": "storage.wasm"}
      ],
      "server_modules_so": [
        {"name": "AuthModule", "file": "auth.so"},
        {"name": "SyncModule", "file": "sync.so"},
        {"name": "AIProxyModule", "file": "ai-proxy.so"},
        {"name": "MonitoringModule", "file": "monitoring.so"}
      ],
      "io": "WebSocket",
      "engine": "HighPerfEngine",
      "ui": "React PWA",
      "storage": "PostgreSQL + IndexedDB",
      "cost": "$3-5/mois"
    }
  },

  "active_mode": "local_dev"
}
```

**Bascule entre modes :**
```json
// Mode local (MVP - Phase 1 OBLIGATOIRE)
"active_mode": "local_dev"

// Mode production (Phase 3 CONDITIONNEL - seulement si Phase 2 validée)
"active_mode": "production_pwa"
```

---

### 4.6 Risques Techniques de l'Architecture Multi-Target

**⚠️ ATTENTION : Cette section documente les risques identifiés de la compilation multi-target (DLL/SO/WASM).**

#### Risques Majeurs Identifiés

| Risque | Impact | Probabilité | Mitigation Proposée |
|--------|--------|-------------|---------------------|
| **Complexité CMake multi-target** | Élevé | Moyenne | Phase 2 POC validera faisabilité avant engagement |
| **Maintenance 3 builds par module** | Moyen | Élevée | Si trop complexe, rester mode `local_dev` uniquement |
| **Performance WASM insuffisante** | Élevé | Moyenne | Benchmarks Phase 2, accepter 2x overhead max |
| **Debugging WASM complexe** | Moyen | Élevée | Développer en DLL (facile), compiler WASM uniquement prod |
| **Différences comportementales DLL/SO/WASM** | Élevé | Faible | Tests automatisés sur 3 targets, CI/CD obligatoire |
| **Emscripten limitations (threads, I/O)** | Moyen | Moyenne | Design modules sans dépendances système (pure logic) |
| **Overhead développement pipeline** | Moyen | Élevée | Si Phase 2 montre complexité excessive, ABANDONNER multi-target |

#### Stratégie de Validation (Phase 2)

**Avant tout engagement Phase 3, Phase 2 DOIT valider :**

1. **POC Technique** (2-3 jours max) :
   - Créer `HelloModule.cpp` minimal (IModule WarFactory)
   - Compiler en `.dll` (Windows MSVC)
   - Compiler en `.wasm` (Emscripten)
   - Tester intégration React + WASM
   - **Go/No-Go** : Si POC échoue ou trop complexe, ARRÊTER ici

2. **Benchmark Performance** (1 jour) :
   - Mesurer overhead WASM vs DLL natif
   - Algorithme test : SchedulerModule (calculs intensifs)
   - **Critère acceptation** : WASM < 2x DLL
   - **Go/No-Go** : Si WASM > 2x, reconsidérer architecture

3. **Évaluation Complexité Build** (1 jour) :
   - Setup complet Emscripten + Docker
   - Temps build 3 targets (DLL + SO + WASM)
   - **Critère acceptation** : < 30 min build complet CI/CD
   - **Go/No-Go** : Si build > 30 min, trop lent pour itérations

#### Scénarios de Sortie

**Si Phase 2 invalide multi-target :**

- **Option A (recommandée)** : Rester 100% mode `local_dev`
  - MVP fonctionnel DLL Windows uniquement
  - $0 coût, 0.4ms hot-reload conservé
  - Abandon PWA/WASM, focus usage perso desktop

- **Option B** : Pivot vers architecture alternative
  - Évaluer Electron (desktop cross-platform)
  - Évaluer Flutter Desktop
  - Réévaluer AlternativesAnalysis.md

**⚠️ ACCEPTER L'ÉCHEC MULTI-TARGET :**
Le mode `local_dev` seul reste une excellente solution pour le besoin initial (hyperfocus management personnel). L'architecture multi-target est un BONUS, pas une nécessité.

---

### 4.7 Architecture Système (Hypothétique - Si Phase 3)

```
┌───────────────────────────────────────────────────────────────┐
│  DÉVELOPPEMENT (Windows PC)                                   │
│  ┌─────────────────────────────────────────────────────────┐  │
│  │  Visual Studio 2022 / VSCode                            │  │
│  │  /modules/                                              │  │
│  │    ├─ SchedulerModule/ (C++)                            │  │
│  │    ├─ StorageModule/ (C++)                              │  │
│  │    ├─ VoiceModule/ (C++)                                │  │
│  │    └─ AIModule/ (C++)                                   │  │
│  │                                                          │  │
│  │  Build Scripts:                                         │  │
│  │    → .dll (Windows dev local)                           │  │
│  │    → .so (Linux serveur via Docker)                     │  │
│  │    → .wasm (Browser client via Emscripten)              │  │
│  └─────────────────────────────────────────────────────────┘  │
└───────────────────────────────────────────────────────────────┘
                          │
                          │ Git Push
                          ▼
┌───────────────────────────────────────────────────────────────┐
│  CI/CD (GitHub Actions)                                       │
│  1. Build backend Linux (Docker)                              │
│  2. Build modules WASM (Emscripten)                           │
│  3. Deploy backend → fly.io                                   │
│  4. Deploy PWA + WASM → Vercel                                │
└───────────────────────────────────────────────────────────────┘
                          │
         ┌────────────────┴────────────────┐
         ▼                                 ▼
┌────────────────────────┐    ┌───────────────────────────────┐
│  SERVEUR (fly.io)      │    │  CLIENT (PWA - Vercel)        │
│  Docker Linux          │    │  React + TypeScript           │
│  ┌──────────────────┐ │    │  ┌─────────────────────────┐  │
│  │ Backend C++      │ │    │  │ UI Components (React)   │  │
│  │ - AuthModule.so  │ │    │  │ - Dashboard             │  │
│  │ - SyncModule.so  │ │    │  │ - Task management       │  │
│  │ - AIProxy.so     │ │    │  │ - Settings              │  │
│  │ - Monitoring.so  │ │    │  └─────────────────────────┘  │
│  │ - WebSocket API  │ │    │                                │
│  └──────────────────┘ │    │  ┌─────────────────────────┐  │
│  PostgreSQL/SQLite    │    │  │ WASM Modules (C++)      │  │
│  Port: 8080 (WSS)     │    │  │ - scheduler.wasm        │  │
└────────┬───────────────┘    │  │ - voice.wasm            │  │
         │                    │  │ - storage.wasm          │  │
         │ WebSocket          │  │   (IndexedDB wrapper)   │  │
         └────────────────────┤  └─────────────────────────┘  │
                              │                                │
                              │  Service Worker (offline)      │
                              │  Web Push API (notifications)  │
                              └────────────────────────────────┘
                                         │
                    ┌────────────────────┼────────────────────┐
                    ▼                    ▼                    ▼
            ┌──────────────┐    ┌──────────────┐    ┌──────────────┐
            │ Windows PC   │    │ iPhone       │    │ Android      │
            │ (Chrome PWA) │    │ (Safari PWA) │    │ (Chrome PWA) │
            └──────────────┘    └──────────────┘    └──────────────┘
                    │                    │                    │
                    └────────────────────┴────────────────────┘
                                         │
                              Tous accèdent à la même PWA
                              https://aissia.app

┌───────────────────────────────────────────────────────────────┐
│  SERVICES EXTERNES                                            │
│  ┌─────────────────────────────────────────────────────────┐  │
│  │ Claude Haiku 4.5 API (Anthropic)                        │  │
│  │ - Appelé UNIQUEMENT par le serveur (API key sécurisée)  │  │
│  │ - Planning suggestions, conversational AI               │  │
│  │ - Coût: ~$10-20/mois usage personnel                    │  │
│  └─────────────────────────────────────────────────────────┘  │
└───────────────────────────────────────────────────────────────┘
```

### 4.8 Répartition Client/Serveur (Hypothétique - Phase 3 uniquement)

| Module | Où ? | Raison | Impact Coût Serveur |
|--------|------|--------|---------------------|
| **SchedulerModule** | ✅ Client (WASM) | Algorithmes purs, pas d'I/O | **Économie $$$** |
| **VoiceModule** | ✅ Client (Web Speech API) | TTS/STT natif browser | **Économie $$$** |
| **StorageModule** | 🔀 Hybrid | IndexedDB client + PostgreSQL serveur | **Économie $$** |
| **UIModule** | ✅ Client (React) | Rendu interface | **Économie $$$** |
| **AIModule** | ❌ Serveur uniquement | Sécurité API key Claude | Nécessaire |
| **AuthModule** | ❌ Serveur uniquement | Sécurité credentials | Nécessaire |
| **SyncModule** | ❌ Serveur uniquement | Base de données centrale | Nécessaire |
| **MonitoringModule** | ❌ Serveur uniquement | Tracking apps desktop impossible en browser | Optionnel |

**Résultat :**
- **70% du processing sur client** (gratuit pour l'utilisateur)
- **Serveur minimaliste** : Auth + Sync + AI proxy + Monitoring
- **Coût serveur** : $3-5/mois au lieu de $20-30/mois

### 4.9 Communication Client-Serveur (Hypothétique - Phase 3 uniquement)

**WebSocket Events (Temps Réel) :**

```typescript
// Client PWA → Serveur
{
  "event": "task_created",
  "data": {
    "task_id": "123",
    "title": "Finir le CDC",
    "priority": "high"
  }
}

// Serveur → Client PWA
{
  "event": "ai_suggestion",
  "data": {
    "message": "Tu devrais faire une pause, ça fait 2h que tu codes",
    "urgency": "medium",
    "actions": ["dismiss", "take_break"]
  }
}
```

**Module WASM (Client-side) :**

```cpp
// SchedulerModule.cpp (compilé en .wasm)
extern "C" {
  // Exporté vers JavaScript
  EMSCRIPTEN_KEEPALIVE
  bool IsProcrastinating(const char* currentApp, const char* tasksJson) {
    // Logique pure C++, tourne dans le browser
    json tasks = json::parse(tasksJson);
    return CheckProcrastination(currentApp, tasks);
  }
}
```

```typescript
// Frontend React appelle le module WASM
import schedulerModule from './wasm/scheduler.wasm';

const isProcrastinating = schedulerModule.IsProcrastinating(
  'steam.exe',
  JSON.stringify(currentTasks)
);

if (isProcrastinating) {
  // Affiche alerte côté client, pas besoin du serveur !
  showNotification('Retourne au travail !');
}
```

**Avantages de cette architecture :**
- ✅ Réactivité instantanée (pas de latence réseau)
- ✅ Fonctionne offline (modules WASM = autonomes)
- ✅ Coûts serveur minimaux
- ✅ Scalabilité : 1000 utilisateurs = même coût serveur

### 4.10 Modèle de Données (Simplifié)

```
User
- id, email, password_hash, created_at
- settings (JSON: notifications, ai_proactivity_level, etc.)

Task
- id, user_id, title, description
- priority (high/medium/low)
- estimated_duration, actual_duration
- deadline, status (todo/in_progress/done)
- tags[], category

TimeEntry
- id, user_id, task_id
- start_time, end_time, duration
- auto_tracked (boolean)

AIInteraction
- id, user_id, timestamp
- type (suggestion/alert/chat)
- context (JSON), ai_response

Schedule
- id, user_id, date
- planned_tasks[] (ordered list)
- ai_generated (boolean)
```

---

## 5. Contraintes et Exigences

### 5.1 Contraintes Techniques
- ✅ **Dev Windows uniquement** : Développement, debug, et tests 100% sur Windows
- ✅ **Cross-platform automatique** : Via Docker (serveur) et WASM (client)
- ✅ **Mobile via PWA** : Progressive Web App (pas d'app native Android/iOS)
- ✅ **Performance** : WASM ~2x plus lent que C++ natif (acceptable)
- ✅ **Offline-first** : Service Workers + IndexedDB + modules WASM autonomes
- ✅ **Sécurité** : JWT auth, HTTPS/WSS obligatoire, API keys serveur uniquement
- ✅ **Pipeline stable** : GitHub Actions (reproductible, pas de surprises)

### 5.2 Contraintes Budget
- 💰 **Mode local_dev (MVP)** : $0 hosting + $10-20/mois Claude API = **$10-20/mois total**
- 💰 **Mode production_pwa (Phase 3)** :
  - Serveur fly.io : $3-5/mois
  - Frontend Vercel : $0 (gratuit)
  - Claude API : $10-20/mois
  - **Total** : $13-25/mois
- 🎯 **Optimisation production_pwa** : 70% processing client → économie serveur massive
- 📊 **Monétisation future** : Freemium (gratuit: 50 requêtes IA/jour, client-side illimité)

### 5.3 Contraintes Développement
- 🔄 **Itérations courtes** : Cycles de 1-2 semaines
- ✅ **Versions fonctionnelles** : Chaque release doit être utilisable
- 🪟 **Dev Windows-first** : Zéro VM/émulateurs, tout sur Windows
- 🐋 **Docker Desktop** : Seul prérequis pour builds cross-platform
- 🧪 **Tests** : Jest (frontend), Google Test (backend C++)
- 📝 **Documentation** : README, architecture diagrams, module interfaces
- 🤖 **CI/CD automatique** : GitHub Actions (build + deploy automatique)

---

## 6. Planification (Roadmap)

**⚠️ IMPORTANT - Structure des phases :**
- **Phase 0 + Phase 1 = OBLIGATOIRES** : Cible MVP mode `local_dev`
- **Phase 2 = VALIDATION** : POC multi-target (Go/No-Go décision)
- **Phase 3 = CONDITIONNELLE** : Seulement SI Phase 2 validée
- **Phase 4 = HYPOTHÉTIQUE** : Dépend succès Phase 3

### Phase 0 - Setup (Semaine 0) - OBLIGATOIRE
- [ ] Copier interfaces WarFactory (IModule, IEngine, IIO, ITaskScheduler, IDataTree)
- [ ] Structure projet modules/ (MonitoringModule/, SchedulerModule/, etc.)
- [ ] CMakeLists.txt pour DLL Windows (Phase 1 uniquement, SO/WASM Phase 2+)
- [ ] gameconfig.json initial (mode `local_dev` uniquement)
- [ ] Scripts build Windows (build-dll.ps1)
- [ ] ⚠️ Setup Docker Desktop (OPTIONNEL - seulement si Phase 2)
- [ ] ⚠️ Setup Emscripten SDK (OPTIONNEL - seulement si Phase 2)

### Phase 1 - MVP Local (Semaines 1-2) - OBLIGATOIRE

**Objectif** : Version locale fonctionnelle avec hot-reload WarFactory (mode `local_dev` DLL uniquement)

**Core Engine :**
- [ ] aissia-core.exe (WarFactory engine)
  - IEngine (DebugEngine)
  - IModuleSystem (SequentialModuleSystem)
  - IIO (IntraIO)
  - ICoordinationModule (charge gameconfig.json)

**Modules DLL (Windows) :**
- [ ] MonitoringModule.dll
  - Win32 API (GetForegroundWindow)
  - Tracking temps par application
  - Publish event "app_changed"
- [ ] SchedulerModule.dll
  - Planning algorithmes basiques
  - Détection procrastination contextuelle
  - Publish event "intervention_needed"
- [ ] AIModule.dll
  - Claude Haiku 4.5 API integration
  - Context building pour suggestions
  - Subscribe "intervention_needed", publish "ai_response"
- [ ] VoiceModule.dll
  - SAPI TTS (Windows text-to-speech)
  - Whisper.cpp STT (speech-to-text local)
  - Subscribe "ai_response", speak()
- [ ] StorageModule.dll
  - SQLite local (aissia.db)
  - CRUD tâches, historique, métriques
- [ ] UIModule-ImGui.dll
  - Dear ImGui interface
  - Dashboard planning
  - Settings

**Bénéfices Phase 1 :**
- ✅ Hot-reload 0.4ms
- ✅ Développement ultra-rapide
- ✅ $0 coût (tout local)
- ✅ Dogfooding immédiat (usage perso)
- ✅ Interventions vocales proactives (besoin core)

---

### Phase 2 - POC WASM (Semaines 3-4) - VALIDATION (Go/No-Go)

**⚠️ CRITIQUE : Cette phase décide si Phase 3 est viable ou non.**

**Objectif** : Valider faisabilité multi-target (WASM) + performance acceptable

**⚠️ RÈGLE : Phase 1 DOIT être complétée et fonctionnelle AVANT Phase 2.**

**POC Expérimental :**
- [ ] Compiler SchedulerModule.wasm (test WASM simple)
- [ ] Frontend React minimal (Vite + TypeScript)
- [ ] Intégrer scheduler.wasm dans React
- [ ] Tester performance WASM vs DLL (benchmark)
- [ ] Évaluer complexité build Emscripten

**Validation Phase 2 (Go/No-Go) :**
- ⚠️ Performance WASM acceptable pour scheduler ? (< 2x DLL)
- ⚠️ Complexité build supportable ? (< 30 min CI/CD)
- ⚠️ Debugging WASM pas trop problématique ?
- ⚠️ Intérêt réel mobile PWA validé par usage Phase 1 ?

**🚦 Décision Go/No-Go :**
- **✅ GO (Phase 3)** : Si TOUS les critères validés ET besoin mobile confirmé
- **❌ NO-GO (Arrêt)** : Si UN SEUL critère invalidé → Rester mode `local_dev` définitif

**⚠️ NO-GO n'est PAS un échec :** Mode `local_dev` seul répond parfaitement au besoin initial.

---

### Phase 3 - Production PWA (Semaines 5-8) - CONDITIONNELLE (Seulement si Phase 2 GO)

**⚠️ ATTENTION : Cette phase n'existe QUE si Phase 2 validée.**

**Objectif** : Déploiement cloud avec PWA React + WASM client

**Backend Docker (Serveur SO) :**
- [ ] auth.so (JWT authentication)
- [ ] sync.so (PostgreSQL synchronisation)
- [ ] ai-proxy.so (Claude API proxy, sécurise API key)
- [ ] websocket-server.so (API temps réel pour clients)
- [ ] Dockerfile backend (Alpine Linux)
- [ ] Deploy fly.io ($3-5/mois)

**Frontend PWA React :**
- [ ] UI complète (Tailwind + shadcn/ui)
- [ ] scheduler.wasm intégré
- [ ] voice.wasm (Web Speech API)
- [ ] storage.wasm (IndexedDB wrapper)
- [ ] Service Workers (offline)
- [ ] Web Push notifications
- [ ] PWA manifest (installable)
- [ ] Deploy Vercel (gratuit)

**CI/CD GitHub Actions :**
- [ ] Build multi-target automatique (DLL/SO/WASM)
- [ ] Deploy backend fly.io
- [ ] Deploy frontend Vercel
- [ ] Tests automatisés

**Mode Dual Opérationnel :**
- Développement Windows : `local_dev` (DLL + ImGui + hot-reload)
- Production : `production_pwa` (WASM + React + Cloud)

---

### Phase 4 - Optimisation & Monétisation (Semaines 9-12) - HYPOTHÉTIQUE (Dépend Phase 3)
- [ ] Système Freemium (rate limiting IA)
- [ ] Paiements Stripe (backend)
- [ ] Landing page marketing
- [ ] Beta publique (early access)
- [ ] Optimisations performance WASM
- [ ] Monitoring & observability (Sentry, Prometheus)

---

## 7. Risques et Mitigations

| Risque | Probabilité | Impact | Mitigation |
|--------|-------------|--------|------------|
| Coût IA trop élevé | Moyenne | Élevé | Caching côté serveur, rate limiting, 70% processing client |
| Complexité WASM | Moyenne | Moyen | Commencer simple (scheduler.wasm), monter progressivement |
| Performance WASM insuffisante | Faible | Moyen | WASM ~2x C++ natif acceptable, fallback serveur possible |
| Docker/Emscripten setup difficile | Faible | Faible | Scripts d'installation automatiques, docs détaillées |
| Adoption utilisateur faible | Élevée | Élevé | Dogfooding (usage perso), beta privée, feedback loops courts |
| Problèmes de privacy | Faible | Critique | Processing client-side, JWT auth, HTTPS/WSS, pas de tracking |
| PWA pas assez "native" | Moyenne | Moyen | Web Push, Service Workers, install prompt, works offline |
| Hyperfocus sur le dev du projet | Élevée | Moyen | Utiliser l'app elle-même pour se contraindre 😅 |

---

## 8. KPIs de Succès

### Phase 1 - MVP Local
- ✅ aissia-core.exe fonctionnel (WarFactory engine)
- ✅ 6 modules DLL opérationnels (monitoring, scheduler, ai, voice, storage, ui)
- ✅ Hot-reload 0.4ms validé
- ✅ Utilisation personnelle quotidienne (dogfooding)
- ✅ Réduction mesurable de l'hyperfocus (via tracking)
- ✅ Interventions vocales proactives fonctionnelles

### Phase 2 - POC WASM (Validation)
- ⚠️ SchedulerModule.wasm compilé et fonctionnel
- ⚠️ Performance WASM acceptable (< 2x C++ natif)
- ⚠️ Intégration React + WASM validée
- ⚠️ Décision Go/No-Go pour Phase 3

### Phase 3 - Production PWA (Si Phase 2 validée)
- 📊 PWA déployée et fonctionnelle (desktop + mobile)
- 📊 100 utilisateurs actifs (beta privée)
- 📊 80%+ retention hebdomadaire
- 📊 NPS > 50
- 💰 $500 MRR (objectif monétisation)
- 🚀 Coût serveur < $10/mois pour 100 users (grâce à WASM client-side)
- ⚡ PWA installée sur 50%+ des devices utilisateurs

---

## 9. Stack Finale Retenue

### Architecture Hybride : WarFactory + Multi-Target (DLL/SO/WASM)

**Concept Révolutionnaire :**
```
MÊME code C++ (IModule WarFactory)
    ↓ CMake multi-target
├─ .dll (Dev Windows local - Hot-reload 0.4ms)
├─ .so  (Serveur Linux Docker - Phase 3)
└─ .wasm (Client PWA browser - Phase 3)
```

**Mode 1 : `local_dev` (Phase 1 MVP) :**
- **Dev** : Windows 10/11, Visual Studio 2022, WarFactory engine
- **Modules** : DLL (monitoring, scheduler, ai, voice, storage, ui-imgui)
- **UI** : Dear ImGui (C++, intégré)
- **Storage** : SQLite local (aissia.db)
- **Coût** : $0 hosting + $10-20/mois Claude API

**Mode 2 : `production_pwa` (Phase 3 - Optionnel) :**
- **Backend** : C++ modules (.so), Docker Linux, fly.io ($3-5/mois)
- **Frontend** : React + TypeScript, WASM modules, Vercel (gratuit)
- **Mobile** : PWA installable (pas d'app native)
- **Coût** : $3-5/mois serveur + $10-20/mois Claude API

**Pourquoi cette architecture hybride :**
- ✅ **Réutilisation WarFactory** : Économie 3-4 semaines dev
- ✅ **Hot-reload 0.4ms** : Productivité maximale en dev local
- ✅ **Types stricts C++** : Pas de wildcode, interfaces bien définies
- ✅ **Évolution progressive** : Commence local ($0), migre cloud si besoin
- ✅ **Modules écrits UNE FOIS** : Compilés en DLL/SO/WASM automatiquement
- ✅ **Déploiement flexible** : gameconfig.json bascule entre modes
- ✅ **Coûts minimaux** : $0 en MVP, $3-5/mois optionnel production
- ✅ **Mobile optionnel** : PWA Phase 3 si besoin validé

**Évolution par phases :**
- **Phase 0** : Setup projet (interfaces WarFactory, CMakeLists multi-target)
- **Phase 1 (MVP)** : Mode `local_dev` (DLL + ImGui + SQLite local)
- **Phase 2 (Validation)** : POC WASM (test performance + faisabilité)
- **Phase 3 (Production)** : Mode `production_pwa` (WASM + React + Cloud) SI validé

**Pourquoi PAS d'autres options :**
- ❌ **Pas de WarFactory** : Perte 3-4 semaines dev + hot-reload 0.4ms
- ❌ **Cloud obligatoire dès MVP** : Coûts permanents + complexité inutile
- ❌ **App native mobile** : Trop complexe, pas prioritaire
- ❌ **Flutter/Node.js** : Pas de réutilisation WarFactory + wildcode
- ❌ **Electron seul** : Poids énorme, pas cross-platform mobile

---

## 10. Prochaines Étapes

### Immédiat (Aujourd'hui)
1. ✅ **CDC draft finalisé** : Architecture proposée et documentée
2. **Validation faisabilité technique** :
   - POC : Hello World C++ → WASM
   - Test setup Emscripten sur Windows
   - Vérifier performance WASM acceptable
3. **Création structure projet** (si POC validé) :
   ```
   aissia/
   ├── modules/          # C++ modules sources
   │   ├── SchedulerModule/
   │   ├── StorageModule/
   │   ├── AIProxyModule/
   │   └── AuthModule/
   ├── backend/          # Serveur C++ Docker
   ├── frontend/         # PWA React
   ├── scripts/          # Build scripts (build-all.ps1)
   ├── .github/workflows/ # CI/CD
   └── docs/            # Documentation
   ```
3. **Setup environnement Windows** :
   - Installer Docker Desktop
   - Installer Emscripten SDK
   - Tester builds multi-target (DLL/SO/WASM)

### Cette Semaine (Phase 0)
4. **Boilerplates** :
   - Backend C++ minimal (CMake, WebSocket server)
   - Frontend React minimal (Vite + TypeScript)
   - Premier module WASM (hello world)
5. **CI/CD GitHub Actions** :
   - Build automatique DLL/SO/WASM
   - Deploy fly.io (backend) + Vercel (frontend)
6. **gameconfig.json initial** :
   - Configuration modules basique
   - Définir stratégie déploiement (client vs serveur)

### Semaine Prochaine (Phase 1)
7. **MVP fonctionnel** :
   - Auth + CRUD tâches
   - scheduler.wasm opérationnel
   - PWA déployée et accessible

---

## Notes

### Principes de Design
- Ce projet répond à un besoin personnel réel
- La proactivité de l'IA est **critique** (pas juste un assistant réactif)
- L'hyperfocus est le problème #1 à résoudre
- Commercialisation = bonus, pas l'objectif principal du MVP

### Contraintes Retenues (Draft)
- 🎯 **Dev 100% Windows** (confort dev prioritaire)
- 🎯 **Cross-platform automatique** (Docker + WASM)
- 🎯 **Mobile via PWA** (pas de dev natif Android/iOS)
- 🎯 **Coûts minimaux** (70% client-side processing)
- 🎯 **Pipeline stable** (GitHub Actions, zéro surprise)

### Décisions Architecturales Proposées (À valider)
1. **Modules C++ partagés** : 1 codebase → DLL/SO/WASM
2. **Client-first** : Déporter calculs sur client pour économiser serveur
3. **PWA installable** : Équivalent app native sans complexité dev
4. **gameconfig.json** : Configuration flexible du déploiement

---

**Status:** 📐 **Architecture Hybride Proposée** - En phase de conception et validation (POC requis)
**Version:** 0.4 - Architecture Hybride Proposée (Hypothétique)
**Date:** 27 octobre 2025

### Proposition Architecturale (À Valider)

**Architecture Proposée : Hybride WarFactory + Multi-Target Conditionnel**

**Concept (Hypothétique) :**
- Un seul code C++ (IModule WarFactory)
- Compilé en 3 targets : DLL (dev local OBLIGATOIRE), SO (serveur CONDITIONNEL), WASM (browser CONDITIONNEL)
- Deux modes de déploiement : `local_dev` (Phase 1 MVP OBLIGATOIRE) et `production_pwa` (Phase 3 CONDITIONNELLE)

**Avantages validés Phase 1 :**
- ✅ Réutilise WarFactory (économie 3-4 semaines validée)
- ✅ Hot-reload 0.4ms en mode local (validé WarFactory)
- ✅ $0 coût en mode local (garanti)
- ✅ Types stricts C++ (validé)

**Avantages hypothétiques Phase 3 (À valider Phase 2) :**
- ⚠️ Évolution progressive vers cloud si besoin (hypothétique)
- ⚠️ Multi-target DLL/SO/WASM viable (à tester)

**Questions ouvertes avant implémentation :**
- ⚠️ Faisabilité réelle compilation multi-target (DLL/SO/WASM) ?
- ⚠️ Complexité CMakeLists.txt multi-target supportable ?
- ⚠️ Performance WASM réellement acceptable (~2x C++ natif) ?
- ⚠️ Effort réel intégration React + WASM ?
- ⚠️ gameconfig.json peut vraiment basculer entre modes sans friction ?

### Prochaines Étapes

**🎯 PRIORITÉ ABSOLUE - Phase 1 (Mode local_dev uniquement) :**

1. **Setup Phase 0** :
   - Interfaces WarFactory
   - Structure projet modules/
   - CMakeLists.txt DLL Windows uniquement (PAS multi-target encore)
   - gameconfig.json mode `local_dev` uniquement

2. **Implémentation Phase 1** :
   - aissia-core.exe (WarFactory engine)
   - 6 modules DLL (monitoring, scheduler, ai, voice, storage, ui-imgui)
   - Validation dogfooding usage personnel

**⚠️ SEULEMENT si Phase 1 complète ET besoin mobile confirmé → Phase 2 (POC WASM)**

**Phase 2 (Validation multi-target) - CONDITIONNEL :**
- POC hello-world .dll + .wasm
- Benchmark performance WASM vs DLL
- Décision Go/No-Go pour Phase 3

**Phase 3+ - CONDITIONNEL (Dépend résultat Phase 2)**

### État Actuel

- 📝 CDC rédigé avec architecture hybride proposée (v0.4)
- 📝 Alternatives analysées et documentées (AlternativesAnalysis.md)
- 📚 Documentation WarFactory copiée dans docs/
- 📝 Retour externe Claude reçu et intégré
- 📝 Section risques techniques ajoutée
- ⏸️ **Phase 1 (local_dev) validée** : Architecture WarFactory DLL prouvée
- ⚠️ **Phases 2-3 (multi-target) hypothétiques** : POC requis avant engagement
- ⏸️ **Pas encore d'implémentation** : Conception et validation uniquement

### Notes Importantes

- **✅ Phase 1 = GO** : Mode `local_dev` est validé et sera implémenté
- **⚠️ Phases 2-3 = CONDITIONNEL** : Multi-target reste hypothétique jusqu'à POC Phase 2
- **Ne PAS setup Emscripten/Docker avant Phase 2** : Éviter complexité prématurée
- **Architecture multi-target = proposition, pas garantie** : Peut être abandonnée
- **Focus MVP Phase 1** : Livrer version locale fonctionnelle d'abord
- **Accepter local_dev seul comme succès** : Si multi-target invalide, pas un échec