尚未偵測到更新。GitHub 發布版本後會顯示在這裡。
個人 GitHub 帳號下公開儲存庫的擁有者可以登入並驗證所有權,自行管理介紹,無需管理員核准。
登入並產生驗證檔案,在 30 分鐘內將其提交至此儲存庫的預設分支。其他分支或分叉儲存庫中的檔案無效。然後在下方檢查檔案,即可無需管理員核准直接管理專案。請保留檔案以維持管理權限。
如需登入,將前往登入頁面。登入後請回到此處,再次點擊所選的驗證按鈕。
在專案資料夾中執行 /nomorevibe verify,即可驗證所有權並自行管理介紹。
一分鐘完成驗證Le prototype de l'expérience conversationnelle à partir d'un univers d'un film de fiction
翻譯準備中
取自儲存庫 README
正在載入完整 README。
檢視完整 README ↗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.
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.
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.md0.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-largeet les interroge avecvoyage-4-litedans 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-4est 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_SECONDSdans 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, PRDdocuments/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 PostHogvoice_turn_completed/voice_error, tables internesvoice_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, Inworldinworld-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. SecretsINWORLD_API_KEYetHUME_API_KEYajoutés. Détails dansCHANGELOG.mdetSTORY.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, rerankerrerank-2.5, filtrage strict parcharacter_id, indexes pgvector HNSW, edge functionsrewrite-queryetsummarize-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.
Expérience narrative interactive voice-to-voice avec plusieurs personnages fictifs pilotés par IA, dans l'univers de "Où est Ava ?".
documents/PRD_Prototype_1.mdValider 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.
| Composant | Technologie |
|---|---|
| Frontend | React + Vite + Tailwind + TypeScript (Lovable) |
| Backend | Lovable Cloud (Supabase Postgres + pgvector) |
| Edge Functions | proxy-llm, proxy-stt, proxy-tts, proxy-tts-inworld, proxy-tts-fish, proxy-tts-cartesia, sync-notion, sync-eval-items, query-rag, sync-questionnaire, rewrite-query, summarize-session |
| Video | Gumlet (hébergement + embed player) |
| Cost Tracking | OpenRouter generation API (tokens + USD per call) |
| LLM | 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. |
| Embeddings | Profils versionnés : Voyage voyage-4-large → voyage-4-lite (1024D recommandé), voyage-context-4 canary, Voyage 3/OpenAI legacy explicites |
| Reranker | Voyage rerank-2.5-lite par défaut live ; rerank-2.5 pour les comparaisons qualité |
| Données | Notion (source de vérité) → Supabase fourni par Lovable (miroir + index parallèles) |
| RAG | query-rag Edge Function + pgvector HNSW + profil actif serveur + filtrage character_id + reranking contextualisé |
Le plan initial visait 5 phases pour réduire les inventions de Max et rendre son comportement éditorialement pilotable.
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.MaxPromptTestTab, mais ne sont pas exécutés dans le PRD4 live.MaxPromptControlTab, MaxPromptTestTab, AntiHallucinationValidatorTab, HallucinationMetricsTab.MaxTurnKnowledgeContext et du prompt validateur.# Cloner
git clone <YOUR_GIT_URL>
# Installer
npm install
# Lancer
npm run dev
Ou directement via Lovable.
Prérequis : migration 20260805120000_rag_embedding_profiles.sql appliquée via Lovable Cloud, secret VOYAGE_API_KEY configuré et données Notion accessibles.
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.
Aller sur /admin → Mécanique → Laboratoire RAG.
| Étape | Contrôle | Détail |
|---|---|---|
| Index | Profil actif | voyage-4-realtime, documents voyage-4-large, questions voyage-4-lite |
| 1. RAG | Profil et modèle | Doit afficher le profil actif réellement lu côté serveur |
| 1. RAG | rerankUsed | Badge présent si RAG_RERANK_ENABLED=true |
| 1. RAG | Par chunk | Vérifier character_id (scopé ou "shared"), retrieval_similarity (cosine brute), rerank_score (Voyage rerank 2.5) |
| 4. Max | Réponse | 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) |
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.
/
├── documents/ # PRD et documentation projet
├── src/
│ ├── agents/ # maxAgent.ts, gameMasterAgent.ts
│ ├── assets/ # Images (portrait Max)
│ ├── components/ # Écrans UI (Onboarding, Conversation, GameOver, etc.)
│ ├── config/ # settings.json (variables configurables)
│ ├── hooks/ # useGameState, useTimer
│ ├── services/ # deepgramSTT, elevenLabsTTS, openRouterLLM, orchestrator, ragService, settingsService, llmUsageTracker, sessionService
│ └── types/ # Types TypeScript partagés
├── public/assets/ # Background images
├── supabase/functions/ # Edge Functions (proxy-llm, proxy-stt, proxy-tts, sync-notion, query-rag, sync-questionnaire)
├── CHANGELOG.md # Historique versionné
├── STORY.md # Journal de développement
└── README.md # Ce fichier
OPENROUTER_API_KEY, DEEPGRAM_API_KEY, ELEVENLABS_API_KEY, ELEVENLABS_VOICE_ID, OPENAI_API_KEY, NOTION_API_KEY, VOYAGE_API_KEYadmin_users) + sandboxes de réglages (prod verrouillé pour le public)/admin/<rubrique>/<page> — sessions, prompts, LLM/voix, Qualité (dont LLM as judge), sync Notion, latencesgeneration_id temporairement introuvablesproxy-tts-cartesia + secret CARTESIA_API_KEY sur Lovable Cloud pour que Tester Cartesia fonctionneProjet Memoways — Storygami
conversation_log/admin protégé par Supabase Auth et comptes nominatifs admin_userselapsed_ms vs timeout_ms) dans l'onglet SessionsSegmentDetailSheet) au clic sur un segment de latencedocuments/guide_game_master_contenus_et_tests.md) — prompts, variables, hypothèses, variantes à testervoyage-3 (1024 dim) en double-stack avec OpenAI + reranker rerank-2.5 appliqué après retrievalvoyage-4-large documents → voyage-4-lite questions), Context 4 canary et activation atomique après rebuild completcharacter_id) sur les chunks RAG (chunks scopés vs partagés)rewrite-query edge function) — reformulation autonome avant RAGsummarize-session + table session_summaries) injectée dans le prompt Maxcharacter_id/rerank_score/retrieval brutsrc/services/tts/ + ElevenLabs / Inworld / Fish Audio / Gradium / Cartesia ; sélection d'un provider par environnement depuis Admin → TTS Config ; intention de jeu par tourrealtime_conversation pour tests voice-to-voice rapides (eleven_turbo_v2_5, MP3 64 kbps, optimizeStreamingLatency=1)voice_turn_completed, erreur unifiée voice_error, corrélation turn_id, stockage Supabase voice_turn_events / voice_error_events, dashboard cible documentéExperiencePhase à 11 états (welcome → film_question → teaser → role_capture → role_summary → character_select → calling_max → conversation_max → end_session → questionnaire → thanks), 9 écrans dédiés (src/components/prd4/*), entrée racine / directement sur IndexPRD4summarize-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_rolesummary_for_max injecté en tête du system prompt de Max avant la personagameMasterPRD4.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éelspokenWith) ; Ava et Léo restent verrouillés. Plan : docs/plan_emma_conversation_switch.mddocs/plan_changement_interlocuteur_manuel.md.characterKey. Plan : docs/plan_gradium_tts_par_personnage.mdPerformanceIntent 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#FFFFFF. Plan : docs/plan_textes_blanc_lisibilite.mdsync-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é)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)OnboardingAScreen, OnboardingBScreen, ABChoiceScreen, OnboardingScreen, GateScreen, pages/Index.tsx et de la route /legacy/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