Portail de veille sur pipelines vocaux (STT, TTS) et avatars vidéo conversationnels. Benchmarks neutres, outils interactifs, dossier Où est Ava ? et analytics PostHog. Genève.
Status Trio is a native macOS menu bar application that integrates Wi-Fi, battery, and volume into a single compact, configurable menu bar icon. It allows for various custom appearance configurations.
Curated reverse-engineering tools and learning resources for binaries, apps, firmware, formats, and protocols.
8h +9★ 1,844Other
Site preview image
Do you operate this project?
Owners of public repositories under a personal GitHub account can sign in to verify ownership and manage the introduction themselves. No administrator approval is needed.
Organization repository · verify with a repository file
Sign in, generate a verification file, and commit it to this repository’s default branch within 30 minutes. Files on other branches or forks do not count. Then check the file below to manage the project without administrator approval. Keep the file to retain your access.
If needed, you will go to sign-in. After signing in, return here and press your chosen verification button again.
Run /nomorevibe verify in your project folder to verify ownership and manage the introduction yourself.
Statut: 🟡 En cours Type: 🧪 Prototype Diffusion: 🔒 Interne uniquement — non public, tests utilisateurs prévus en septembre 2026
Créé avec: Lovable Démarré: 2026-03-07
Correctif publié via Lovable (2026-10-14) — Tavus et transcription : transcription utilisateur visible en direct puis après envoi, sans sous-titres personnage ; flux Tavus conservé entre rendus React, préparation audio + vidéo et erreurs de lecture explicites. Deepgram attend l'acquittement de la fin audio, avec récupération bornée. Diagnostics réseau/CPU disponibles. Recette confirmée par Ulrich après deux échanges avec Max dans l'expérience publiée, environnement sandbox-ulrich, sur Brave. Plan et validation.
Plateforme de référence
Lovable compile le code et publie le site. Le backend, la base de données, les Edge Functions et les secrets passent par Lovable Cloud, avec Supabase fourni par Lovable. Il ne faut pas remplacer cette chaîne par un build, un déploiement, un hébergeur ou un projet Supabase externe.
Les développements réalisés depuis un autre environnement doivent rester compatibles avec Lovable et être ramenés dans le projet Lovable avant toute validation ou publication. Les instructions obligatoires destinées à tous les agents et outils du dépôt sont dans AGENTS.md.
Accès aux données Lovable Cloud depuis un assistant
Utiliser le connecteur MCP app Ava, serveur ava-prototype-1, endpoint
https://iralfqlslqndgvexixis.supabase.co/functions/v1/mcp, avec OAuth admin.
Il expose list_sessions, get_usage_overview, get_llm_costs et
get_voice_latencies en lecture seule, sans dialogue ni secret. Le connecteur
Supabase générique n'est pas le point d'accès aux données de ce Cloud Lovable ;
son refus ne justifie pas de demander une reconnexion pour Ava.
Contrat et limites : plan MCP ; diagnostics
V2 et preuves réelles : bilan P0.
Les quatre outils ont été vérifiés via le connecteur natif le 14 octobre 2026,
après republication du correctif JSON Schema P2 ; mesures absentes conservées
à null. Pour une vérification technique ciblée non exposée par ces outils,
le MCP Lovable query_database cible ce même projet/Cloud après vérification
de son identité ; sélectionner uniquement les métadonnées nécessaires.
Livraison et réserves : bilan P2.
La mise en public est bloquée par la release gate. Un aperçu interne peut être utilisé pour le développement, mais aucun lien ne doit être diffusé à des testeurs externes avant validation des critères de sécurité, persistance et endurance.
Mise à jour récente (2026-09-11) — relations crédibles, GM et mesures AVA : chaque personnage suit une politique relationnelle versionnée avec trois paliers cachés, résistance et initiative propres à son caractère. Le GM post-tour propose les évolutions sans ralentir la réponse ; un moteur déterministe contrôle puis mémorise l'état séparément pour chaque personnage. Les mesures internes AVA sont la source principale du diagnostic de réactivité, rapprochées de PostHog par session et par tour. Plan et état de validation : docs/plan_orchestration_experience_et_reglages_gm.md.
Mise à jour récente (2026-08-25) — Emma, TTS émotionnel, LLM as judge : le joueur peut démarrer avec Emma et basculer Max ↔ Emma sans fuite de mémoire ; chaque tour dérive une intention de jeu TTS (PerformanceIntent) mappée vers Hume / Inworld / ElevenLabs / Gradium / Cartesia, avec réglages Gradium distincts par personnage ; l’admin Qualité lance un banc d’essai texte LLM as judge (corpus Notion, OFAT modèle / sampling / RAG, classement vs live). Détails : CHANGELOG.md 0.27–0.30, STORY.md, docs/plan_emma_conversation_switch.md, docs/plan_tts_pilotage_emotionnel.md, docs/plan_llm_as_judge.md.
Mise à jour récente (2026-08-21) — environnements de réglages et accès nominatifs : le runtime public reste verrouillé sur prod, tandis que les membres authentifiés disposent de trois sandboxes isolées. Le portail public est vérifié côté Lovable Cloud et les sessions sont attribuées par compte, environnement, contexte et campagne. Plan d'activation et checklist : docs/plan_environnements_sandbox_auth.md.
Mise à jour récente (2026-08-05) — RAG Voyage 4 versionné : le profil temps réel recommandé indexe les documents avec voyage-4-large et les interroge avec voyage-4-lite dans leur espace vectoriel partagé. Les profils sont construits en parallèle puis activés atomiquement ; le dashboard RAG affiche l’index effectif, les modèles, le chunking, les volumes et les p50/p95 live. voyage-context-4 est disponible en canary, sans overlap. Analyse, plan et trajectoire mémoire/payload : docs/design/DESIGN-001-rag-voyage4-memoire-payload.md.
Mise à jour récente (2026-07-30) — Streaming Avatar piloté par Ava : l’output public peut rendre le texte final inchangé de Max avec le TTS local, HeyGen LiveAvatar ou Tavus. Les fournisseurs avatar ne participent ni au STT, ni au RAG, ni au raisonnement. L’activation reste en canary, avec TTS par défaut. Procédure Lovable Cloud : docs/streaming-avatar-lovable-setup.md.
Mise à jour récente (2026-07-21) — traces causales de Max : les administrateurs peuvent lancer une session PRD4 explicitement tracée et inspecter chaque tour (mémoire, RAG et scores, prompt assemblé, payload OpenRouter exact, modèle, réponse et latences). La trace causale est enregistrée avant l’affichage et le TTS ; en cas d’échec d’écriture, le tour n’est pas diffusé et peut être rejoué. Détails : docs/max-causal-tracing.md.
Mise à jour récente (2026-07-13) — télémétrie des tests internes : le panneau voix/analytics est temporairement masqué et les événements techniques PostHog/Grain sont actifs par défaut. Le panneau final reste disponible avec VITE_PRIVACY_NOTICE_ENABLED=true. Autocapture, replay, profils persistants et texte libre restent exclus. Détails : docs/phase4_privacy_prepublic_runbook.md.
Mise à jour précédente (2026-07-13) — Phase 3 : canary interne : la durée est pilotée uniquement par TIMEOUT_SECONDS dans le slider admin ; le timer et le Game Master suivent cette valeur. Les seuils de promotion/rollback sont codifiés, la persistance devient observable et PostHog n'utilise plus autocapture ni session replay. Détails : docs/phase3_internal_canary_runbook.md.
Mise à jour précédente (2026-07-13) — Phase 2 : fluidité et endurance configurable : contexte LLM borné, résumé persistant, RAG fail-soft et annulation des tours obsolètes. Le watchdog protège l'attente de la première voix sans limiter la durée d'une lecture TTS en cours. Les tests couvrent 1 050 tours orchestrateur, un soak navigateur de 35 tours et une réponse audio dépassant le watchdog. Détails : docs/phase2_fluidity_endurance_report.md.
Mise à jour récente (2026-05-22) — PRD4 : nouveau parcours post-film + rôle utilisateur + Max contextualisé : refonte structurante livrée en 6 phases. L'onboarding A/B est supprimé au profit d'un parcours unique « tu viens de voir le film, tu appelles quelqu'un ». Le joueur définit son rôle à la voix (push-to-talk + résumé Gemini Flash), Max reçoit ce rôle dans son system prompt, 4 personnages s'affichent (Max actif, Emma/Ava/Léo grisés), le GM pré-tour est retiré du chemin temps réel et le GM post-turn tourne en async (sessions.gm_post_turn_log). Nouveau questionnaire 10 questions + mapping Notion avec accents exacts. Back-office enrichi (rôle utilisateur + timeline GM post-turn). Détails : CHANGELOG.md, STORY.md, docs/plan_prd4_implementation.md, PRD documents/PRD_4_prototype_mai_2026.md.
Mise à jour précédente (2026-05-22) — Robustesse voix multi-navigateurs + optimisation latence live + observabilité PostHog : audit détaillé du pipeline vocal Max (docs/audit_voice_conversation_max.md) puis durcissement du runtime voix : sélection MIME STT, timeouts critiques, audio unlock, lecture TTS robuste, preset Conversation temps réel, silence STT réduit à 900 ms. Deuxième passe latence : Gemini 2.0 Flash, réponses limitées à 220 tokens / 1-2 phrases, RAG compacté, suppression du GM pré-tour LLM du hot path. Troisième passe observabilité : turn_id, événements PostHog voice_turn_completed / voice_error, tables internes voice_turn_events / voice_error_events, et stats back-office end-to-end.
Mise à jour précédente (2026-05-16) — TTS multi-providers + voix Alain (Inworld) + monitoring « Consommation Voix » : refonte du TTS en façade découplée (src/services/tts/) avec 3 providers branchés — ElevenLabs, Inworld inworld-tts-2 (voix « Alain » en streaming NDJSON, deliveryMode STABLE/BALANCED/CREATIVE) et Hume AI Octave. Sélection d'un seul provider actif global depuis Admin → TTS Config, sans redéploiement, avec bouton 🔊 Tester par provider. Nouveau dashboard « Consommation Voix » : compteurs, taux de succès, latences p50/p95 (first-byte + total), distribution des codes HTTP et erreurs récentes par provider. Secrets INWORLD_API_KEY et HUME_API_KEY ajoutés. Détails dans CHANGELOG.md et STORY.md.
Mise à jour précédente (2026-05-10) — RAG v2 (Voyage AI + reranker + query rewriting + mémoire de session) : embeddings Voyage AI voyage-3 (1024 dim) en double-stack avec OpenAI, reranker rerank-2.5, filtrage strict par character_id, indexes pgvector HNSW, edge functions rewrite-query et summarize-session.
Mise à jour précédente: banc d'essai complet « Test de réponse Max » — refonte de l'onglet en outil d'inspection du pipeline conversationnel étape par étape (RAG → Knowledge → GM pré-tour → Max → Validateur). Document de plan : docs/plan_max_test_inspector.md.
En une phrase
Expérience narrative interactive voice-to-voice avec plusieurs personnages fictifs pilotés par IA, dans l'univers de "Où est Ava ?".
Notion: Bases éditoriales AVA (Characters, Storyworld, Gameplay, Vidéos)
Dernière sync: 2026-03-08
🎯 Objectif projet
Valider le pipeline complet d'une conversation voice-to-voice multipersonnage : STT (Deepgram) → LLM (OpenRouter/multi-modèles) → TTS multi-providers, orchestré par un Game Master post-tour qui gère une relation progressive, les triggers vidéo et le game over, enrichi par un pipeline RAG connecté à Notion.
Le chantier en cours suit le plan documents/plan_implementation_max.md pour mieux séparer l'identité de Max, les connaissances autorisées, les contraintes de révélation et la supervision éditoriale du Game Master.
✅ Livrables
Pipeline voice-to-voice complet (STT → LLM → TTS)
Agent Max conversationnel (prompt système, streaming)
Agent Game Master orchestrateur (JSON structuré)
Système de triggers vidéo (Gumlet player + fallback placeholder)
OpenRouter API — Multi-modèles. Chemin live optimisé sur Gemini 2.0 Flash par défaut ; modèles plus lourds réservés aux tests/qualité depuis l'admin (dont banc LLM as judge).
STT
Deepgram (WebSocket streaming + VAD) avec sélection MIME MediaRecorder à l'exécution et timeouts token/micro/WebSocket
TTS
Multi-providers via façade src/services/tts/ — ElevenLabs, Inworld, Fish Audio, Gradium, Cartesia ; intention de jeu par tour (PerformanceIntent) ; Gradium réglable Max/Emma séparément. Provider actif dans Admin → TTS Config.
Le plan initial visait 5 phases pour réduire les inventions de Max et rendre son comportement éditorialement pilotable.
Déjà implémenté
PRD4 live : Max reçoit mémoire bornée, résumé de session, RAG, contexte temporel, profil joueur et éventuelle guidance GM du tour précédent.
Traçabilité : PipelineTraceTab relie chaque réponse diffusée à son entrée, son prompt, son payload OpenRouter exact, ses chunks RAG, ses réglages et ses latences.
Game Master live : labels en parallèle et évaluation post-tour ; ces traitements sont séparés des causes de la réponse actuelle.
Outils de simulation : GM pré-tour et validateur restent disponibles dans MaxPromptTestTab, mais ne sont pas exécutés dans le PRD4 live.
Prérequis : migration 20260805120000_rag_embedding_profiles.sql appliquée via Lovable Cloud, secret VOYAGE_API_KEY configuré et données Notion accessibles.
1. Construire le profil
Dans /admin → 🔎 Configuration RAG, sélectionner Voyage 4 · temps réel, puis Construire et activer. Le profil courant reste actif jusqu’au succès complet.
Doit s'appuyer sur les chunks rerankés, pas inventer hors contexte
5. Mémoire session
Historique de 4+ tours
Après 4 tours utilisateur, un résumé est généré et réinjecté dans le prompt (visible dans le contexte final de Max sous SOUVENIRS DE LA SESSION)
4. Test rapide d'ambiguïté
Saisir un historique avec un message ambigu (antécédent manquant) et vérifier que le pipeline affiche la requête réécrite avant le RAG. Sans rewrite, le RAG retourne des chunks incohérents ; avec rewrite, les chunks doivent revenir cohérents avec le sujet rétabli.
Les réglages admin sont persistés en base (survivent au rechargement et changement de navigateur) ; overrides du banc d’essai restent en mémoire seulement
Le tracking de coûts OpenRouter est tolérant aux délais d'indexation et aux generation_id temporairement introuvables
Open Window : déployer proxy-tts-cartesia + secret CARTESIA_API_KEY sur Lovable Cloud pour que Tester Cartesia fonctionne
Pipeline PRD4 parallélisé (labels GM en parallèle de Max, GM post-tour destiné au tour suivant)
Validateur du simulateur en mode fail-open (timeout 4s + résilience aux JSON malformés)
Panneau admin "Latence & blocage" : timings par étape (RAG/GM/Max/validateur/TTS) + détection du point de blocage
Accès /admin protégé par Supabase Auth et comptes nominatifs admin_users
Visualisation comparative multi-sessions des latences réelles (barres empilées par session)
Détail par tour dépliable depuis chaque barre de session, avec marqueur de cible 2 s commun
Indicateur de dispersion par session (bracket min–max + écart-type σ sur le total des tours)
Filtres sessions (période, nombre min de tours, présence de blocage) + auto-dépliage au focus
Mini-graphique GM fallback (elapsed_ms vs timeout_ms) dans l'onglet Sessions
Diagnostic factuel des latences au survol des segments (budget cible, ratio vs médiane, p95, hypothèses d'optimisation)
Panneau latéral détaillé (SegmentDetailSheet) au clic sur un segment de latence
Filtre "Sévérité min." dans la vue latence (atténuation visuelle des segments sous le seuil)
Guide Game Master (documents/guide_game_master_contenus_et_tests.md) — prompts, variables, hypothèses, variantes à tester
Banc d'essai complet d'inspection du pipeline Max (RAG → Knowledge → GM Pre → Max → Validator) avec chronologie, tokens, latences, contexte injecté décomposé, brief GM JSON, prompt système final, diagnostic validateur, export JSON et presets rapides
Embeddings Voyage AI voyage-3 (1024 dim) en double-stack avec OpenAI + reranker rerank-2.5 appliqué après retrieval
Profils RAG versionnés : Voyage 4 temps réel (voyage-4-large documents → voyage-4-lite questions), Context 4 canary et activation atomique après rebuild complet
Filtrage strict par personnage (character_id) sur les chunks RAG (chunks scopés vs partagés)
Indexes pgvector HNSW (m=16) — fix scoring quasi-nul sur petits datasets vs ivfflat
TTS multi-providers : façade src/services/tts/ + ElevenLabs / Inworld / Fish Audio / Gradium / Cartesia ; sélection d'un provider par environnement depuis Admin → TTS Config ; intention de jeu par tour
Dashboard « Consommation Voix » : compteurs, taux de succès, latences p50/p95 (first-byte + total), codes HTTP et erreurs récentes par provider
Robustesse voix multi-navigateurs : sélection MIME STT à l'exécution, timeouts critiques, audio unlock, erreurs TTS/STT trackées et état conversationnel récupérable
Optimisation latence live Max : modèle live rapide par défaut, contexte RAG compacté, GM pré-tour LLM retiré du chemin temps réel, réponses orales bornées à 1-2 phrases
PRD4 — Rôle joueur libre : capture push-to-talk + edge function summarize-role (Gemini 2.5 Flash) qui produit un UserRoleProfile JSON (summary_for_user, summary_for_max, relationship_to_family, age, gender, proximity_level, intent), persistance sessions.player_role
PRD4 — Max contextualisé par le rôle : résumé summary_for_max injecté en tête du system prompt de Max avant la persona
PRD4 — GM post-turn async : agent gameMasterPRD4.ts évalue chaque tour (engagement_delta, role_usage_quality, confusion, topics, end_recommended, next_turn_guidance), persistance append-only dans sessions.gm_post_turn_log, GM pré-tour retiré du chemin temps réel
PRD4 — Grille personnages : grille 2×2 (Max, Emma, Ava, Léo) ; à l’origine Max seul actif, Emma/Ava/Léo grisés ; écran d’appel avec sonneries ~3 s
Emma joignable + switch Max ↔ Emma : démarrage avec Max ou Emma dès qu’Orchestration les active ; demande joueur ou suggestion GM ; mémoire / résumé / sous-titres isolés par personnage (spokenWith) ; Ava et Léo restent verrouillés. Plan : docs/plan_emma_conversation_switch.md
Appel Max ↔ Emma proposé par le GM : bouton uniquement après recommandation validée du GM et accord du personnage ; choix Appeler/Rester, coupure du micro, trois sonneries puis réponse. Session et temps restant conservés. Plan et livraison : docs/plan_changement_interlocuteur_manuel.md.
Gradium TTS par personnage : réglages fins distincts Max / Emma dans TTS Config ; le runtime envoie characterKey. Plan : docs/plan_gradium_tts_par_personnage.md
Pilotage émotionnel TTS : PerformanceIntent par tour (lexique FR + mémoire GM N−1) mappé vers Fish Audio, Inworld, ElevenLabs, Gradium et Cartesia ; audition admin + labels d’utilisabilité. Plan : docs/plan_tts_pilotage_emotionnel.md
PRD4 — Nouveau questionnaire (10 questions) : film vu, teaser utile, clarté création rôle, justesse résumé, clarté/frustration PTT, Max reconnaît rôle, Max crédible, envie autres personnages, prochain personnage souhaité, durée ressentie, feedback ouvert + email + 2 opt-ins ; métriques techniques calculées automatiquement
PRD4 — Sync Notion avec noms exacts (accents) : sync-questionnaire détecte version: "prd4" et écrit dans les propriétés Notion accentuées (PRD4 Rôle création clarté, PRD4 Résumé personnage justesse, PRD4 Max reconnaît rôle, PRD4 Personnage souhaité prochain, PRD4 Durée ressentie, PRD4 Rôle JSON, PRD4 Être tenu au courant, PRD4 Contact feedback détaillé…), filtrage côté serveur des propriétés absentes via fetchDatabaseProperties() (skipped_props logué)
PRD4 — Back-office enrichi : SessionsTab admin affiche le rôle joueur (résumés + JSON repliable) et une timeline gm_post_turn_log compacte (engagement, role usage, confusion, end, modération, latence ms, sujets, next_turn_guidance)
PRD4 — Nettoyage legacy : suppression de OnboardingAScreen, OnboardingBScreen, ABChoiceScreen, OnboardingScreen, GateScreen, pages/Index.tsx et de la route /legacy
LLM as judge (lot 1) : onglet Qualité /admin/qualite/llm-as-judge, sync corpus Notion (or + grille), OFAT texte-only (modèle Max / sampling / RAG, catalogue partagé avec LLM Config), juge LLM à température 0, classement Δ vs live ; tables eval_* + Edge Function sync-eval-items. Continuité d'expérience = lot 2. Plan : docs/plan_llm_as_judge.md
Video triggers dynamiques (depuis DB au lieu de hardcodés)
Politique de vérité à 4 niveaux (certain / probable / inconnu / interdit)
Bible factuelle éditable et gestion explicite des sujets verrouillés/déverrouillés
