aissia/CDCDraft.md

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 :

// 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 :

// 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 :

// 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 :

# 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 :

# 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 :

{
  "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 :

// 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) :

// 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) :

// 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);
  }
}

// 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
   

4. 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