From 0acf2cc7f1ccfefb1937fbe8a20ff0341aa9e4ee Mon Sep 17 00:00:00 2001
From: Bgk Injector SqLi <81836350+borisbob91@users.noreply.github.com>
Date: Mon, 13 Jul 2026 02:45:27 +0000
Subject: [PATCH 1/7] docs(livekit): define LK09 production hardening sprint

---
 .../SPRINT-LK-09-production-hardening.md      | 328 ++++++++++++++++++
 1 file changed, 328 insertions(+)
 create mode 100644 sprints/livekit/SPRINT-LK-09-production-hardening.md

diff --git a/sprints/livekit/SPRINT-LK-09-production-hardening.md b/sprints/livekit/SPRINT-LK-09-production-hardening.md
new file mode 100644
index 0000000..f94989e
--- /dev/null
+++ b/sprints/livekit/SPRINT-LK-09-production-hardening.md
@@ -0,0 +1,328 @@
+# SPRINT-LK-09 - Production, telephonie et durcissement du socle
+
+## Statut
+
+- **Etat** : planifie
+- **Branche de travail recommandee** : `feat/sprint-lk09-production-hardening`
+- **Prerequis** : LK00 a LK08 integres sur `master`
+- **Objectif principal** : transformer l'integration LiveKit actuelle, deja fonctionnelle pour les rooms et le runtime optionnel, en une capacite exploitable en production avec telephonie SIP, deploiement reproductible, observabilite sure et validation end-to-end.
+
+## Constat verifie dans le code
+
+Le runtime LiveKit optionnel, le bridge DomOS, l'endpoint de token, l'integration React room, les tests de base et la documentation d'exploitation existent deja. Les adaptateurs Anthropic et la persistance SQLite/MongoDB existent egalement : ils ne doivent pas etre recrees dans ce sprint.
+
+Les lacunes encore actives sont :
+
+1. La telephonie SIP entrante et sortante n'est pas implementee.
+2. Le lien metier complet entre appel, room, participant et session DomOS doit etre ferme.
+3. La configuration des trunks, numeros et regles de dispatch n'a pas de surface DomOS finalisee.
+4. Aucun scenario telephonique reel ne valide toute la chaine.
+5. Le deploiement actuel reste principalement une reference/demo et doit devenir reproductible.
+6. L'observabilite doit couvrir la telephonie sans exposer de secrets.
+7. Les pannes et reprises LiveKit doivent etre testees explicitement.
+8. Le contrat de `DomOSClient.send()` sans transport ouvert reste ambigu.
+9. Le handshake WebRTC complet n'a pas de test end-to-end.
+10. DevTools ne compare pas clairement les tools locaux avec la surface effective du serveur.
+
+## Hors scope
+
+- Reimplementation de `@domos/adapter-anthropic`.
+- Reimplementation des stores SQLite ou MongoDB.
+- Remplacement du protocole ADTP.
+- Couplage obligatoire du serveur core a LiveKit.
+- Stockage de token, secret, contexte brut, arguments ou resultats de tools dans le dashboard ou les logs.
+- Refonte generale des packages React, Vue, Svelte ou Angular.
+
+## Principes d'architecture
+
+- LiveKit reste un module optionnel. DomOS Server doit demarrer sans dependance ou configuration LiveKit.
+- DomOS reste proprietaire de la session, du Shadow Context, du registre de tools, des approvals et des politiques de securite.
+- LiveKit gere la room, les participants, les medias temps reel et la couche SIP.
+- Gemini ne devient jamais obligatoire : la couche LiveKit doit rester ouverte a plusieurs providers.
+- Une session sans UI expose uniquement les tools serveur.
+- Une UI connectee ajoute ses tools montes; leur demontage les retire de la surface effective.
+- Toutes les erreurs externes sont converties en erreurs DomOS stables, redigees et sans secret.
+
+---
+
+## Lot A - Telephonie LiveKit
+
+### Tache 1 - Implementer la telephonie SIP entrante et sortante
+
+**But** : permettre a DomOS de recevoir et d'initier un appel via LiveKit SIP.
+
+**Implementation** :
+
+1. Ajouter un domaine `sip` dans `packages/adapter-livekit/src/` sans melanger cette logique avec le bridge agent existant.
+2. Definir des types publics minimaux pour trunk, numero, direction, dispatch rule et call state.
+3. Fournir une facade de haut niveau pour creer/fermer un appel et normaliser les evenements LiveKit.
+4. Mapper les etats `ringing`, `active`, `ended` et `failed` vers des evenements DomOS stables.
+5. Garder les imports LiveKit lazy ou isoles afin de preserver le runtime optionnel.
+6. Rediger les erreurs provider avant de les transmettre au serveur ou au dashboard.
+
+**Fichiers cibles probables** :
+
+- `packages/adapter-livekit/src/sip/types.ts`
+- `packages/adapter-livekit/src/sip/LiveKitSipService.ts`
+- `packages/adapter-livekit/src/sip/index.ts`
+- `packages/adapter-livekit/src/index.ts`
+- `packages/adapter-livekit/tests/LiveKitSipService.test.ts`
+
+**Acceptation** :
+
+- [ ] Un appel entrant peut etre accepte et associe a une room.
+- [ ] Un appel sortant peut etre cree depuis une commande serveur.
+- [ ] Aucun secret SIP n'est transmis au navigateur.
+- [ ] Le package build sans configuration LiveKit active.
+
+### Tache 2 - Relier les appels LiveKit aux sessions DomOS
+
+**But** : rendre le cycle call/room/participant/session coherent et observable.
+
+**Implementation** :
+
+1. Introduire un identifiant de correlation non secret entre appel, room et session DomOS.
+2. Etendre `DomOSLiveKitAgentBridge` par composition, sans dupliquer le pipeline de tools.
+3. Creer la session DomOS au bon moment, puis attacher le participant telephonique.
+4. Appliquer la regle tools serveur seuls tant qu'aucune UI n'est connectee.
+5. Synchroniser les tools client au montage et au demontage lorsque le provider le supporte.
+6. Lorsque l'update mid-session n'est pas supportee, exposer clairement la limitation et appliquer la nouvelle surface a la prochaine session.
+7. Fermer proprement les ressources a la fin de l'appel sans detruire arbitrairement une session texte encore active.
+
+**Acceptation** :
+
+- [ ] Chaque appel actif possede une correlation call/room/participant/session.
+- [ ] Les tools client ne sont jamais executes cote serveur par erreur.
+- [ ] Le cleanup est idempotent.
+- [ ] Une deconnexion room ne casse pas le mode texte restant.
+
+### Tache 3 - Ajouter le routage des appels et la configuration SIP
+
+**But** : fournir une configuration exploitable sans hardcode.
+
+**Implementation** :
+
+1. Definir un schema de configuration pour trunks entrants/sortants, numeros et dispatch rules.
+2. Charger les secrets uniquement depuis l'environnement ou un secret manager.
+3. Valider la configuration au demarrage avec des messages d'erreur actionnables.
+4. Ajouter des exemples neutres dans `.env.example`, sans valeur reelle.
+5. Documenter le provisionnement LiveKit Cloud et self-hosted.
+6. Ajouter une politique CORS et d'origine explicite pour les endpoints publics associes.
+
+**Acceptation** :
+
+- [ ] Une configuration invalide echoue proprement sans afficher de secret.
+- [ ] Une configuration absente desactive uniquement SIP/LiveKit.
+- [ ] Les regles entrantes et sortantes sont testables separement.
+
+### Tache 4 - Valider un appel telephonique LiveKit de bout en bout
+
+**But** : prouver que la chaine complete fonctionne, pas seulement les unites.
+
+**Scenario de reference** :
+
+1. Demarrer DomOS Server avec LiveKit active.
+2. Recevoir ou initier un appel SIP.
+3. Creer la room et lier la session DomOS.
+4. Echanger de l'audio dans les deux sens.
+5. Executer un tool serveur.
+6. Connecter une UI et verifier l'apparition de ses tools.
+7. Demonter l'UI et verifier leur retrait.
+8. Terminer l'appel et verifier le cleanup.
+
+**Acceptation** :
+
+- [ ] Le scenario est automatise ou fourni sous forme de harnais reproductible.
+- [ ] Les preuves de test ne contiennent aucun secret.
+- [ ] Les echecs indiquent l'etape exacte en cause.
+
+---
+
+## Lot B - Deploiement et observabilite
+
+### Tache 5 - Deployer DomOS Server et LiveKit dans un environnement reel
+
+**But** : passer de la demo a un deploiement reproductible.
+
+**Implementation** :
+
+1. Definir une topologie cible : DomOS Server, endpoint de token, LiveKit, stockage persistant et reverse proxy TLS.
+2. Fournir une configuration par environnement avec validation au boot.
+3. Ajouter des health checks separes pour DomOS et l'integration LiveKit.
+4. Documenter DNS, TLS, CORS, URL WebSocket et rotation des secrets.
+5. Ajouter une procedure de migration et rollback.
+6. Verifier que le serveur reste fonctionnel lorsque LiveKit est desactive.
+
+**Points d'appui existants** :
+
+- `apps/demo-server/src/livekitTokenEndpoint.ts`
+- `packages/server/.env.example`
+- `docs/LIVEKIT.md`
+- `docs/livekit/telephony-deploy-observability.md`
+
+**Acceptation** :
+
+- [ ] Un environnement vierge peut etre deploye avec la documentation seule.
+- [ ] Les health checks distinguent panne DomOS et panne LiveKit.
+- [ ] Le rollback est documente et teste.
+
+### Tache 6 - Finaliser l'observabilite LiveKit sans fuite de secrets
+
+**But** : rendre l'exploitation compréhensible et sure.
+
+**Implementation** :
+
+1. Exposer l'etat configure/non configure de LiveKit.
+2. Afficher rooms, participants, etat d'appel et correlation de session avec des identifiants rediges.
+3. Ajouter logs structures, compteurs d'appels, erreurs par categorie, latence de connexion et duree de session.
+4. Interdire explicitement tokens, cles, contexte brut, args et resultats de tools.
+5. Ajouter une verification automatique de redaction dans les tests.
+6. Completer le dashboard existant, sans construire une seconde interface d'administration.
+
+**Acceptation** :
+
+- [ ] Un operateur peut diagnostiquer un appel sans acces aux secrets.
+- [ ] Les logs permettent de suivre une correlation sans PII brute.
+- [ ] Les tests echouent si un secret connu apparait dans une sortie.
+
+### Tache 7 - Tester la resilience et la reprise du runtime LiveKit
+
+**But** : eviter qu'une panne externe bloque DomOS.
+
+**Cas a couvrir** :
+
+- LiveKit non configure.
+- Credentials invalides.
+- Endpoint de token indisponible.
+- Room interrompue.
+- Participant deconnecte brutalement.
+- Provider realtime indisponible.
+- Redemarrage du serveur.
+- Cleanup execute plusieurs fois.
+
+**Acceptation** :
+
+- [ ] Le mode texte reste utilisable lorsque le media tombe.
+- [ ] Aucun etat `connecting` ne reste bloque indefiniment.
+- [ ] Les ressources et listeners sont liberes.
+- [ ] Un runbook court indique diagnostic, mitigation et reprise.
+
+---
+
+## Lot C - Socle et validation SDK
+
+### Tache 8 - Definir le comportement de send sans transport ouvert
+
+**But** : fermer l'ambiguite du contrat public de `DomOSClient.send()`.
+
+**Implementation** :
+
+1. Choisir un contrat unique et documente pour `disconnected`, `connecting` et `reconnecting`.
+2. Privilegier une erreur typee et actionnable si aucune file d'attente fiable n'existe deja.
+3. Eviter une file infinie ou silencieuse.
+4. Aligner browser, tests et documentation publique.
+5. Verifier que les appels internes existants gerent le nouveau contrat.
+
+**Acceptation** :
+
+- [ ] Aucun envoi n'est perdu silencieusement.
+- [ ] Le comportement est identique pour tous les transports.
+- [ ] Les tests couvrent chaque etat de connexion.
+
+### Tache 9 - Ajouter le test WebRTC complet du handshake client
+
+**But** : couvrir le chemin reel qui manque encore dans les audits.
+
+**Scenario** :
+
+1. Ouvrir un `DataChannel` mocke.
+2. Verifier l'emission de `HANDSHAKE_INIT`.
+3. Verifier `Authorization` et `lineToken`.
+4. Injecter `HANDSHAKE_ACK`.
+5. Verifier la transition vers l'etat connecte.
+6. Couvrir timeout, ACK invalide et fermeture avant ACK.
+
+**Acceptation** :
+
+- [ ] Le chemin `DataChannel.open -> HANDSHAKE_INIT -> HANDSHAKE_ACK` passe.
+- [ ] Les erreurs ne laissent aucun timer ou listener actif.
+- [ ] Le test ne depend pas d'un service reseau externe.
+
+### Tache 10 - Comparer les tools locaux a la surface serveur dans DevTools
+
+**But** : rendre visibles les divergences du registre de tools.
+
+**Implementation** :
+
+1. Reutiliser les evenements standardises du core.
+2. Afficher tools locaux, tools acceptes par le serveur et surface effective.
+3. Signaler absences, collisions, versions differentes et tools retires.
+4. Montrer l'effet du montage/demontage des composants.
+5. Ne jamais afficher les arguments ou resultats sensibles par defaut.
+
+**Acceptation** :
+
+- [ ] Une divergence est identifiable sans lire les logs bruts.
+- [ ] La vue se met a jour pendant le cycle mount/unmount.
+- [ ] Aucun nouveau protocole parallele n'est introduit.
+
+---
+
+## Ordre d'execution recommande
+
+1. Tache 8 : verrouiller le contrat `send()` avant d'etendre les scenarios reseau.
+2. Tache 9 : fermer le handshake WebRTC manquant.
+3. Tache 1 : fondation SIP.
+4. Tache 3 : configuration et routage.
+5. Tache 2 : correlation call/room/session.
+6. Tache 6 : observabilite necessaire au debug.
+7. Tache 5 : deploiement cible.
+8. Tache 7 : resilience et reprise.
+9. Tache 4 : validation telephonique end-to-end.
+10. Tache 10 : surface DevTools finale.
+
+## Strategie de tests
+
+Executer au minimum :
+
+```bash
+pnpm --filter @domos/core build
+pnpm --filter @domos/core test
+pnpm --filter @domos/adapter-livekit build
+pnpm --filter @domos/adapter-livekit test
+pnpm --filter @domos/server build
+pnpm --filter @domos/server test
+pnpm --filter @domos/react build
+pnpm --filter @domos/react test
+pnpm --filter @domos/ui build
+pnpm --filter @domos/ui test
+pnpm test
+```
+
+Ajouter :
+
+- tests unitaires des services SIP;
+- tests d'integration du bridge call/room/session;
+- test WebRTC complet sans reseau externe;
+- test de redaction des logs;
+- test de runtime sans LiveKit installe/configure;
+- harnais end-to-end telephonique documente.
+
+## Gates finales
+
+- [ ] LiveKit reste optionnel dans DomOS Server.
+- [ ] Un appel entrant et un appel sortant sont supportes.
+- [ ] Call, room, participant et session sont correles proprement.
+- [ ] Les tools serveur/client respectent leur lieu d'execution.
+- [ ] Le deploiement TLS/CORS/secrets est reproductible.
+- [ ] Le dashboard et les logs ne divulguent aucune donnee sensible.
+- [ ] Les pannes LiveKit ne bloquent pas durablement le mode texte.
+- [ ] `DomOSClient.send()` possede un contrat public teste.
+- [ ] Le handshake WebRTC complet est couvert.
+- [ ] DevTools montre la surface effective des tools.
+- [ ] Les builds et tests des packages touches passent.
+- [ ] La documentation LiveKit et les exemples sont synchronises avec le code final.
+
+## Definition of Done
+
+Le sprint est termine uniquement lorsqu'un environnement neuf peut deployer DomOS avec LiveKit, recevoir ou initier un appel SIP, relier cet appel a une session DomOS, executer les tools au bon endroit, survivre aux pannes testees et fournir assez d'observabilite pour diagnostiquer le systeme sans exposer de secret. Toute case historique non cochee mais deja implementee doit etre corrigee dans la documentation au lieu de generer du travail en doublon.

From 8487be263f87095cae1d9ad81cd9b2224ea76e89 Mon Sep 17 00:00:00 2001
From: Bgk Injector SqLi <81836350+borisbob91@users.noreply.github.com>
Date: Mon, 13 Jul 2026 02:51:18 +0000
Subject: [PATCH 2/7] docs(livekit): refocus LK09 on web deployment readiness

---
 .../SPRINT-LK-09-production-hardening.md      | 457 ++++++++++--------
 1 file changed, 252 insertions(+), 205 deletions(-)

diff --git a/sprints/livekit/SPRINT-LK-09-production-hardening.md b/sprints/livekit/SPRINT-LK-09-production-hardening.md
index f94989e..d688ac4 100644
--- a/sprints/livekit/SPRINT-LK-09-production-hardening.md
+++ b/sprints/livekit/SPRINT-LK-09-production-hardening.md
@@ -1,290 +1,331 @@
-# SPRINT-LK-09 - Production, telephonie et durcissement du socle
+# SPRINT-LK-09 - Deploiement web LiveKit et durcissement production
 
 ## Statut
 
 - **Etat** : planifie
-- **Branche de travail recommandee** : `feat/sprint-lk09-production-hardening`
-- **Prerequis** : LK00 a LK08 integres sur `master`
-- **Objectif principal** : transformer l'integration LiveKit actuelle, deja fonctionnelle pour les rooms et le runtime optionnel, en une capacite exploitable en production avec telephonie SIP, deploiement reproductible, observabilite sure et validation end-to-end.
+- **Cible** : DomOS integre comme widget dans une page web
+- **Prerequis** : runtime LiveKit optionnel et sprints LK00 a LK08 integres sur `master`
+- **Objectif** : rendre le serveur DomOS et le canal audio LiveKit deployables, configurables et validables dans un environnement web reel.
 
-## Constat verifie dans le code
+## Decision de scope
 
-Le runtime LiveKit optionnel, le bridge DomOS, l'endpoint de token, l'integration React room, les tests de base et la documentation d'exploitation existent deja. Les adaptateurs Anthropic et la persistance SQLite/MongoDB existent egalement : ils ne doivent pas etre recrees dans ce sprint.
+La telephonie SIP ne fait pas partie de ce sprint. DomOS vit actuellement dans un widget web : LiveKit sert au transport audio temps reel entre le navigateur et l'agent. ADTP reste le canal canonique pour le Shadow Context, les tools, les approvals et leurs resultats.
 
-Les lacunes encore actives sont :
+La telephonie pourra etre traitee plus tard comme extension produit distincte si un cas d'usage centre d'appels ou appels entrants/sortants est valide.
 
-1. La telephonie SIP entrante et sortante n'est pas implementee.
-2. Le lien metier complet entre appel, room, participant et session DomOS doit etre ferme.
-3. La configuration des trunks, numeros et regles de dispatch n'a pas de surface DomOS finalisee.
-4. Aucun scenario telephonique reel ne valide toute la chaine.
-5. Le deploiement actuel reste principalement une reference/demo et doit devenir reproductible.
-6. L'observabilite doit couvrir la telephonie sans exposer de secrets.
-7. Les pannes et reprises LiveKit doivent etre testees explicitement.
-8. Le contrat de `DomOSClient.send()` sans transport ouvert reste ambigu.
-9. Le handshake WebRTC complet n'a pas de test end-to-end.
-10. DevTools ne compare pas clairement les tools locaux avec la surface effective du serveur.
+## Etat actuel verifie
 
-## Hors scope
+Deja present dans le code :
 
-- Reimplementation de `@domos/adapter-anthropic`.
-- Reimplementation des stores SQLite ou MongoDB.
-- Remplacement du protocole ADTP.
-- Couplage obligatoire du serveur core a LiveKit.
-- Stockage de token, secret, contexte brut, arguments ou resultats de tools dans le dashboard ou les logs.
-- Refonte generale des packages React, Vue, Svelte ou Angular.
+- `@domos/adapter-livekit` et runtime LiveKit optionnel ;
+- hook React `useDomOSLiveKitRoom` ;
+- bouton de demonstration `LiveKitRoomButton` ;
+- endpoint serveur `POST /domos/livekit/token` ;
+- verification API key et possession de session avant emission du token ;
+- tokens de room a duree courte ;
+- allowlist CORS via `DOMOS_LIVEKIT_ALLOWED_ORIGINS` ;
+- bridge entre session DomOS et AgentSession LiveKit ;
+- redaction des donnees sensibles dans la surface d'administration ;
+- documentation de configuration LiveKit.
+
+Elements reellement manquants pour un deploiement web :
 
-## Principes d'architecture
+1. Image Docker de production pour DomOS Server.
+2. Fichier Compose ou equivalent pour lancer DomOS avec ses dependances.
+3. Commande de demarrage production claire pour le serveur.
+4. Configuration complete et validee par environnement.
+5. Reverse proxy HTTPS/WSS et politique CORS de production.
+6. Health checks et readiness checks.
+7. Procedure de deploiement LiveKit Cloud ou self-hosted.
+8. Validation end-to-end du widget depuis un domaine public.
+9. Observabilite et procedure de reprise.
+10. Fermeture de deux lacunes SDK deja auditees : contrat `send()` et handshake WebRTC complet.
 
-- LiveKit reste un module optionnel. DomOS Server doit demarrer sans dependance ou configuration LiveKit.
-- DomOS reste proprietaire de la session, du Shadow Context, du registre de tools, des approvals et des politiques de securite.
-- LiveKit gere la room, les participants, les medias temps reel et la couche SIP.
-- Gemini ne devient jamais obligatoire : la couche LiveKit doit rester ouverte a plusieurs providers.
-- Une session sans UI expose uniquement les tools serveur.
-- Une UI connectee ajoute ses tools montes; leur demontage les retire de la surface effective.
-- Toutes les erreurs externes sont converties en erreurs DomOS stables, redigees et sans secret.
+## Hors scope
+
+- Telephonie SIP, trunks et numeros de telephone.
+- Reimplementation Anthropic.
+- Reimplementation des stores SQLite ou MongoDB.
+- Remplacement d'ADTP par LiveKit.
+- Couplage obligatoire de `@domos/server` a LiveKit.
+- Refonte generale des widgets React, Vue, Svelte ou Angular.
 
 ---
 
-## Lot A - Telephonie LiveKit
+## Lot A - Packaging du serveur
 
-### Tache 1 - Implementer la telephonie SIP entrante et sortante
+### Tache 1 - Ajouter une image Docker de production pour DomOS Server
 
-**But** : permettre a DomOS de recevoir et d'initier un appel via LiveKit SIP.
+**But** : produire une image reproductible, minimale et exploitable hors du monorepo local.
 
 **Implementation** :
 
-1. Ajouter un domaine `sip` dans `packages/adapter-livekit/src/` sans melanger cette logique avec le bridge agent existant.
-2. Definir des types publics minimaux pour trunk, numero, direction, dispatch rule et call state.
-3. Fournir une facade de haut niveau pour creer/fermer un appel et normaliser les evenements LiveKit.
-4. Mapper les etats `ringing`, `active`, `ended` et `failed` vers des evenements DomOS stables.
-5. Garder les imports LiveKit lazy ou isoles afin de preserver le runtime optionnel.
-6. Rediger les erreurs provider avant de les transmettre au serveur ou au dashboard.
+1. Creer un Dockerfile multi-stage pour installer avec `pnpm --frozen-lockfile`, builder les packages requis et ne copier que les artefacts necessaires au runtime.
+2. Utiliser une version Node LTS explicite et un utilisateur non-root.
+3. Exposer uniquement le port du serveur DomOS.
+4. Ajouter un `.dockerignore` pour exclure caches, secrets, rapports et `node_modules` locaux.
+5. Verifier que LiveKit reste optionnel : l'image doit demarrer sans variables LiveKit.
+6. Ajouter un health check conteneur sans exposer de secret.
 
 **Fichiers cibles probables** :
 
-- `packages/adapter-livekit/src/sip/types.ts`
-- `packages/adapter-livekit/src/sip/LiveKitSipService.ts`
-- `packages/adapter-livekit/src/sip/index.ts`
-- `packages/adapter-livekit/src/index.ts`
-- `packages/adapter-livekit/tests/LiveKitSipService.test.ts`
+- `apps/demo-server/Dockerfile`
+- `.dockerignore`
+- `apps/demo-server/package.json`
+- `apps/demo-server/src/server.ts`
 
 **Acceptation** :
 
-- [ ] Un appel entrant peut etre accepte et associe a une room.
-- [ ] Un appel sortant peut etre cree depuis une commande serveur.
-- [ ] Aucun secret SIP n'est transmis au navigateur.
-- [ ] Le package build sans configuration LiveKit active.
+- [ ] `docker build` reussit depuis la racine.
+- [ ] Le conteneur demarre sans LiveKit.
+- [ ] Le conteneur demarre avec LiveKit lorsque les variables sont fournies.
+- [ ] Aucun secret n'est embarque dans l'image.
+- [ ] Le processus ne tourne pas en root.
 
-### Tache 2 - Relier les appels LiveKit aux sessions DomOS
+### Tache 2 - Ajouter une composition locale et une reference de production
 
-**But** : rendre le cycle call/room/participant/session coherent et observable.
+**But** : lancer l'ensemble avec une commande documentee.
 
 **Implementation** :
 
-1. Introduire un identifiant de correlation non secret entre appel, room et session DomOS.
-2. Etendre `DomOSLiveKitAgentBridge` par composition, sans dupliquer le pipeline de tools.
-3. Creer la session DomOS au bon moment, puis attacher le participant telephonique.
-4. Appliquer la regle tools serveur seuls tant qu'aucune UI n'est connectee.
-5. Synchroniser les tools client au montage et au demontage lorsque le provider le supporte.
-6. Lorsque l'update mid-session n'est pas supportee, exposer clairement la limitation et appliquer la nouvelle surface a la prochaine session.
-7. Fermer proprement les ressources a la fin de l'appel sans detruire arbitrairement une session texte encore active.
-
-**Acceptation** :
-
-- [ ] Chaque appel actif possede une correlation call/room/participant/session.
-- [ ] Les tools client ne sont jamais executes cote serveur par erreur.
-- [ ] Le cleanup est idempotent.
-- [ ] Une deconnexion room ne casse pas le mode texte restant.
-
-### Tache 3 - Ajouter le routage des appels et la configuration SIP
-
-**But** : fournir une configuration exploitable sans hardcode.
+1. Ajouter un fichier Compose pour DomOS Server et les dependances reellement necessaires.
+2. Prevoir deux profils LiveKit : Cloud externe et LiveKit self-hosted.
+3. Ne pas embarquer LiveKit self-hosted dans le profil par defaut.
+4. Monter les secrets via variables ou fichiers ignores par Git.
+5. Ajouter les volumes persistants uniquement lorsque SQLite ou un service externe l'exige.
+6. Documenter les differences entre developpement, staging et production.
 
-**Implementation** :
+**Fichiers cibles probables** :
 
-1. Definir un schema de configuration pour trunks entrants/sortants, numeros et dispatch rules.
-2. Charger les secrets uniquement depuis l'environnement ou un secret manager.
-3. Valider la configuration au demarrage avec des messages d'erreur actionnables.
-4. Ajouter des exemples neutres dans `.env.example`, sans valeur reelle.
-5. Documenter le provisionnement LiveKit Cloud et self-hosted.
-6. Ajouter une politique CORS et d'origine explicite pour les endpoints publics associes.
+- `compose.yaml`
+- `.env.example`
+- `docs/DEPLOYMENT.md`
 
 **Acceptation** :
 
-- [ ] Une configuration invalide echoue proprement sans afficher de secret.
-- [ ] Une configuration absente desactive uniquement SIP/LiveKit.
-- [ ] Les regles entrantes et sortantes sont testables separement.
+- [ ] `docker compose up` lance DomOS en mode texte.
+- [ ] Le profil LiveKit Cloud fonctionne sans conteneur LiveKit local.
+- [ ] Le profil self-hosted documente ports, TURN et stockage.
+- [ ] Aucun mot de passe par defaut dangereux n'est fourni.
 
-### Tache 4 - Valider un appel telephonique LiveKit de bout en bout
+### Tache 3 - Definir une commande de demarrage production stable
 
-**But** : prouver que la chaine complete fonctionne, pas seulement les unites.
+**But** : ne plus dependre d'une commande de developpement implicite.
 
-**Scenario de reference** :
+**Implementation** :
 
-1. Demarrer DomOS Server avec LiveKit active.
-2. Recevoir ou initier un appel SIP.
-3. Creer la room et lier la session DomOS.
-4. Echanger de l'audio dans les deux sens.
-5. Executer un tool serveur.
-6. Connecter une UI et verifier l'apparition de ses tools.
-7. Demonter l'UI et verifier leur retrait.
-8. Terminer l'appel et verifier le cleanup.
+1. Ajouter un script `start` production au serveur deploye.
+2. S'assurer que le build genere tous les fichiers executes au runtime.
+3. Gerer correctement `SIGTERM` et `SIGINT` : fermeture WebSocket, sessions, bridge LiveKit et connexions de persistence.
+4. Retourner un code de sortie non nul si la configuration obligatoire DomOS est invalide.
+5. Ne pas bloquer le boot si les variables LiveKit optionnelles sont absentes.
 
 **Acceptation** :
 
-- [ ] Le scenario est automatise ou fourni sous forme de harnais reproductible.
-- [ ] Les preuves de test ne contiennent aucun secret.
-- [ ] Les echecs indiquent l'etape exacte en cause.
+- [ ] `pnpm --filter <serveur> build` puis `pnpm --filter <serveur> start` fonctionne.
+- [ ] L'arret du conteneur est propre et borne dans le temps.
+- [ ] Une mauvaise configuration produit une erreur actionnable.
 
 ---
 
-## Lot B - Deploiement et observabilite
-
-### Tache 5 - Deployer DomOS Server et LiveKit dans un environnement reel
+## Lot B - Configuration reseau et securite
 
-**But** : passer de la demo a un deploiement reproductible.
+### Tache 4 - Finaliser la configuration par environnement
 
-**Implementation** :
+**Variables serveur minimales a documenter** :
 
-1. Definir une topologie cible : DomOS Server, endpoint de token, LiveKit, stockage persistant et reverse proxy TLS.
-2. Fournir une configuration par environnement avec validation au boot.
-3. Ajouter des health checks separes pour DomOS et l'integration LiveKit.
-4. Documenter DNS, TLS, CORS, URL WebSocket et rotation des secrets.
-5. Ajouter une procedure de migration et rollback.
-6. Verifier que le serveur reste fonctionnel lorsque LiveKit est desactive.
+```env
+LIVEKIT_URL=wss://your-livekit-host
+LIVEKIT_API_KEY=...
+LIVEKIT_API_SECRET=...
+GOOGLE_API_KEY=...
+DOMOS_LIVEKIT_ALLOWED_ORIGINS=https://app.example.com
+DOMOS_REQUIRE_API_KEY=true
+```
 
-**Points d'appui existants** :
+**Implementation** :
 
-- `apps/demo-server/src/livekitTokenEndpoint.ts`
-- `packages/server/.env.example`
-- `docs/LIVEKIT.md`
-- `docs/livekit/telephony-deploy-observability.md`
+1. Centraliser la lecture et la validation des variables de production.
+2. Refuser une `LIVEKIT_URL` non TLS en production.
+3. Refuser les wildcards CORS en production sauf opt-in explicite et visible.
+4. Conserver `LIVEKIT_API_SECRET`, les cles provider et les credentials de persistence uniquement cote serveur.
+5. Documenter la rotation des cles sans rebuild du widget.
+6. Fournir des exemples distincts pour local et production.
 
 **Acceptation** :
 
-- [ ] Un environnement vierge peut etre deploye avec la documentation seule.
-- [ ] Les health checks distinguent panne DomOS et panne LiveKit.
-- [ ] Le rollback est documente et teste.
+- [ ] La configuration manquante indique precisement la variable concernee.
+- [ ] Les secrets ne sont jamais inclus dans les bundles navigateur.
+- [ ] Changer une origine autorisee ne demande pas de rebuilder le widget.
 
-### Tache 6 - Finaliser l'observabilite LiveKit sans fuite de secrets
+### Tache 5 - Ajouter le reverse proxy HTTPS et WebSocket
 
-**But** : rendre l'exploitation compréhensible et sure.
+**But** : servir DomOS en HTTPS/WSS depuis un domaine public.
 
 **Implementation** :
 
-1. Exposer l'etat configure/non configure de LiveKit.
-2. Afficher rooms, participants, etat d'appel et correlation de session avec des identifiants rediges.
-3. Ajouter logs structures, compteurs d'appels, erreurs par categorie, latence de connexion et duree de session.
-4. Interdire explicitement tokens, cles, contexte brut, args et resultats de tools.
-5. Ajouter une verification automatique de redaction dans les tests.
-6. Completer le dashboard existant, sans construire une seconde interface d'administration.
+1. Fournir une configuration de reference Caddy ou Nginx.
+2. Router le WebSocket DomOS et l'endpoint `/domos/livekit/token`.
+3. Preserver les headers d'upgrade WebSocket.
+4. Appliquer TLS, limites de taille, timeouts et rate limiting raisonnables.
+5. Restreindre CORS au domaine du widget.
+6. Documenter les contraintes proxy/load balancer pour les connexions longues.
 
 **Acceptation** :
 
-- [ ] Un operateur peut diagnostiquer un appel sans acces aux secrets.
-- [ ] Les logs permettent de suivre une correlation sans PII brute.
-- [ ] Les tests echouent si un secret connu apparait dans une sortie.
+- [ ] Le widget se connecte via `wss://` depuis un domaine distinct.
+- [ ] Le token endpoint refuse une origine non autorisee.
+- [ ] Les connexions longues ne sont pas coupees par un timeout proxy trop court.
 
-### Tache 7 - Tester la resilience et la reprise du runtime LiveKit
+### Tache 6 - Documenter LiveKit Cloud et LiveKit self-hosted
 
-**But** : eviter qu'une panne externe bloque DomOS.
+**LiveKit Cloud** :
 
-**Cas a couvrir** :
+1. Creer un projet LiveKit.
+2. Recuperer URL, API key et API secret.
+3. Injecter ces valeurs uniquement dans le runtime serveur.
+4. Autoriser le domaine public du widget dans DomOS.
+5. Verifier la region et les contraintes reseau des utilisateurs cibles.
 
-- LiveKit non configure.
-- Credentials invalides.
-- Endpoint de token indisponible.
-- Room interrompue.
-- Participant deconnecte brutalement.
-- Provider realtime indisponible.
-- Redemarrage du serveur.
-- Cleanup execute plusieurs fois.
+**Self-hosted** :
+
+1. Documenter domaine TLS, certificat, TURN, ports UDP/TCP et load balancer.
+2. Separer metriques LiveKit et metriques bridge DomOS.
+3. Garder Redis et le multi-node LiveKit hors de `@domos/server`.
+4. Fournir des liens vers la documentation LiveKit officielle pour les composants d'infrastructure.
 
 **Acceptation** :
 
-- [ ] Le mode texte reste utilisable lorsque le media tombe.
-- [ ] Aucun etat `connecting` ne reste bloque indefiniment.
-- [ ] Les ressources et listeners sont liberes.
-- [ ] Un runbook court indique diagnostic, mitigation et reprise.
+- [ ] Un developpeur peut choisir Cloud ou self-hosted sans modifier le widget.
+- [ ] Les exigences TURN et ports sont explicites.
+- [ ] Les secrets LiveKit restent absents du navigateur.
 
 ---
 
-## Lot C - Socle et validation SDK
+## Lot C - Exploitation et validation
 
-### Tache 8 - Definir le comportement de send sans transport ouvert
+### Tache 7 - Ajouter health, readiness et observabilite de production
 
-**But** : fermer l'ambiguite du contrat public de `DomOSClient.send()`.
+**But** : distinguer un serveur vivant d'un serveur pret a accepter des sessions.
 
 **Implementation** :
 
-1. Choisir un contrat unique et documente pour `disconnected`, `connecting` et `reconnecting`.
-2. Privilegier une erreur typee et actionnable si aucune file d'attente fiable n'existe deja.
-3. Eviter une file infinie ou silencieuse.
-4. Aligner browser, tests et documentation publique.
-5. Verifier que les appels internes existants gerent le nouveau contrat.
+1. Ajouter un endpoint liveness pour le processus DomOS.
+2. Ajouter un endpoint readiness validant la configuration et les dependances obligatoires.
+3. Rapporter LiveKit comme `disabled`, `ready` ou `degraded` sans rendre son absence fatale.
+4. Ajouter logs structures avec identifiant de correlation redige.
+5. Mesurer connexions widget, sessions, echecs de token, rooms et temps de connexion.
+6. Ne jamais logger token, secret, contexte brut, arguments ou resultats de tools.
 
 **Acceptation** :
 
-- [ ] Aucun envoi n'est perdu silencieusement.
-- [ ] Le comportement est identique pour tous les transports.
-- [ ] Les tests couvrent chaque etat de connexion.
+- [ ] L'orchestrateur peut distinguer `alive` et `ready`.
+- [ ] Une panne LiveKit place le media en `degraded` sans tuer le mode texte.
+- [ ] Les tests detectent une fuite de secret connue.
+
+### Tache 8 - Valider le widget web de bout en bout sur un domaine public
 
-### Tache 9 - Ajouter le test WebRTC complet du handshake client
+**Scenario obligatoire** :
 
-**But** : couvrir le chemin reel qui manque encore dans les audits.
+1. Deployer DomOS Server derriere HTTPS/WSS.
+2. Configurer une instance LiveKit Cloud ou self-hosted.
+3. Deployer le widget sur un second domaine HTTPS.
+4. Ouvrir une session DomOS avec API key.
+5. Demander un token room au serveur.
+6. Rejoindre/quitter la room depuis le navigateur.
+7. Autoriser le microphone et envoyer l'audio.
+8. Recevoir texte ou audio agent.
+9. Executer un tool via ADTP et verifier que LiveKit ne remplace pas ce canal.
+10. Tester Chrome et Firefox, puis un navigateur mobile.
 
-**Scenario** :
+**Cas d'erreur** :
 
-1. Ouvrir un `DataChannel` mocke.
-2. Verifier l'emission de `HANDSHAKE_INIT`.
-3. Verifier `Authorization` et `lineToken`.
-4. Injecter `HANDSHAKE_ACK`.
-5. Verifier la transition vers l'etat connecte.
-6. Couvrir timeout, ACK invalide et fermeture avant ACK.
+- origine CORS refusee ;
+- microphone refuse ;
+- token expire ;
+- LiveKit indisponible ;
+- WebSocket DomOS interrompu ;
+- room fermee pendant que le mode texte reste actif.
 
 **Acceptation** :
 
-- [ ] Le chemin `DataChannel.open -> HANDSHAKE_INIT -> HANDSHAKE_ACK` passe.
-- [ ] Les erreurs ne laissent aucun timer ou listener actif.
-- [ ] Le test ne depend pas d'un service reseau externe.
+- [ ] Le parcours principal fonctionne sur un domaine public.
+- [ ] Le mode texte survit a une panne LiveKit lorsque la session ADTP reste ouverte.
+- [ ] Les erreurs sont visibles et actionnables dans le widget.
+- [ ] Les preuves de test ne contiennent aucun secret.
 
-### Tache 10 - Comparer les tools locaux a la surface serveur dans DevTools
+### Tache 9 - Ajouter un runbook de deploiement, rollback et reprise
 
-**But** : rendre visibles les divergences du registre de tools.
+**Contenu** :
 
-**Implementation** :
+1. Prerequis DNS, TLS, Node, stockage et LiveKit.
+2. Build, migration, demarrage et verification.
+3. Rotation des secrets.
+4. Diagnostic d'une erreur WebSocket, CORS, token ou media.
+5. Rollback vers l'image precedente.
+6. Sauvegarde et restauration des donnees persistantes.
+7. Procedure lorsque LiveKit tombe mais DomOS texte reste disponible.
+
+**Acceptation** :
+
+- [ ] Le runbook permet un deploiement neuf sans connaissance implicite du monorepo.
+- [ ] Le rollback est teste au moins une fois en staging.
+- [ ] Les commandes ne contiennent aucune valeur secrete reelle.
+
+---
+
+## Lot D - Lacunes SDK bloquantes
+
+### Tache 10 - Fermer les lacunes de transport avant publication
+
+#### 10.1 Definir `DomOSClient.send()` sans transport ouvert
+
+1. Choisir un contrat unique pour `disconnected`, `connecting` et `reconnecting`.
+2. Eviter tout envoi perdu silencieusement et toute file infinie.
+3. Retourner une erreur typee et actionnable si aucun mecanisme fiable de queue n'existe.
+4. Aligner implementation, tests et documentation.
 
-1. Reutiliser les evenements standardises du core.
-2. Afficher tools locaux, tools acceptes par le serveur et surface effective.
-3. Signaler absences, collisions, versions differentes et tools retires.
-4. Montrer l'effet du montage/demontage des composants.
-5. Ne jamais afficher les arguments ou resultats sensibles par defaut.
+#### 10.2 Ajouter le test WebRTC complet
+
+Couvrir :
+
+```text
+DataChannel.open
+  -> HANDSHAKE_INIT
+  -> verification Authorization + lineToken
+  -> HANDSHAKE_ACK
+  -> etat connected
+```
+
+Ajouter les cas timeout, ACK invalide et fermeture avant ACK, sans service reseau externe.
+
+#### 10.3 Completer DevTools
+
+Comparer les tools locaux, les tools acceptes par le serveur et la surface effective. Signaler absences, collisions, versions differentes et changements mount/unmount sans exposer d'arguments sensibles.
 
 **Acceptation** :
 
-- [ ] Une divergence est identifiable sans lire les logs bruts.
-- [ ] La vue se met a jour pendant le cycle mount/unmount.
-- [ ] Aucun nouveau protocole parallele n'est introduit.
+- [ ] `send()` possede un contrat public teste.
+- [ ] Le handshake WebRTC complet est couvert.
+- [ ] DevTools montre les divergences du registre de tools.
 
 ---
 
 ## Ordre d'execution recommande
 
-1. Tache 8 : verrouiller le contrat `send()` avant d'etendre les scenarios reseau.
-2. Tache 9 : fermer le handshake WebRTC manquant.
-3. Tache 1 : fondation SIP.
-4. Tache 3 : configuration et routage.
-5. Tache 2 : correlation call/room/session.
-6. Tache 6 : observabilite necessaire au debug.
-7. Tache 5 : deploiement cible.
-8. Tache 7 : resilience et reprise.
-9. Tache 4 : validation telephonique end-to-end.
-10. Tache 10 : surface DevTools finale.
+1. Commande production et validation de configuration.
+2. Dockerfile serveur.
+3. Compose et profils LiveKit.
+4. Health/readiness.
+5. Reverse proxy HTTPS/WSS.
+6. Guide LiveKit Cloud/self-hosted.
+7. Deploiement staging.
+8. Test widget end-to-end public.
+9. Observabilite, runbook et rollback.
+10. Lacunes SDK de transport et DevTools.
 
 ## Strategie de tests
 
-Executer au minimum :
-
 ```bash
 pnpm --filter @domos/core build
 pnpm --filter @domos/core test
@@ -296,33 +337,39 @@ pnpm --filter @domos/react build
 pnpm --filter @domos/react test
 pnpm --filter @domos/ui build
 pnpm --filter @domos/ui test
+pnpm --filter @domos/demo build
 pnpm test
+
+docker build -f apps/demo-server/Dockerfile .
+docker compose config
+docker compose up -d
 ```
 
-Ajouter :
+Ajouter un smoke test public automatisable pour :
 
-- tests unitaires des services SIP;
-- tests d'integration du bridge call/room/session;
-- test WebRTC complet sans reseau externe;
-- test de redaction des logs;
-- test de runtime sans LiveKit installe/configure;
-- harnais end-to-end telephonique documente.
+- ouverture WebSocket DomOS ;
+- creation de session ;
+- emission d'un token LiveKit ;
+- connexion room ;
+- publication microphone ;
+- maintien du mode texte lorsque LiveKit est coupe.
 
 ## Gates finales
 
-- [ ] LiveKit reste optionnel dans DomOS Server.
-- [ ] Un appel entrant et un appel sortant sont supportes.
-- [ ] Call, room, participant et session sont correles proprement.
-- [ ] Les tools serveur/client respectent leur lieu d'execution.
-- [ ] Le deploiement TLS/CORS/secrets est reproductible.
-- [ ] Le dashboard et les logs ne divulguent aucune donnee sensible.
-- [ ] Les pannes LiveKit ne bloquent pas durablement le mode texte.
-- [ ] `DomOSClient.send()` possede un contrat public teste.
-- [ ] Le handshake WebRTC complet est couvert.
-- [ ] DevTools montre la surface effective des tools.
-- [ ] Les builds et tests des packages touches passent.
-- [ ] La documentation LiveKit et les exemples sont synchronises avec le code final.
+- [ ] Une image serveur production est disponible.
+- [ ] Une commande Compose ou equivalente lance l'environnement.
+- [ ] DomOS fonctionne sans LiveKit configure.
+- [ ] LiveKit fonctionne avec Cloud ou self-hosted sans modifier le widget.
+- [ ] HTTPS, WSS et CORS sont configures pour un vrai domaine.
+- [ ] Liveness et readiness sont exploitables par un orchestrateur.
+- [ ] Aucun secret LiveKit ou provider n'atteint le navigateur.
+- [ ] Le widget rejoint une room depuis un domaine public.
+- [ ] Le microphone et le retour agent fonctionnent dans les navigateurs cibles.
+- [ ] Une panne LiveKit ne supprime pas arbitrairement la session texte ADTP.
+- [ ] Logs, dashboard et preuves de test ne divulguent aucune donnee sensible.
+- [ ] Le deploiement et le rollback sont documentes et testes.
+- [ ] Les lacunes `send()`, handshake WebRTC et DevTools sont fermees.
 
 ## Definition of Done
 
-Le sprint est termine uniquement lorsqu'un environnement neuf peut deployer DomOS avec LiveKit, recevoir ou initier un appel SIP, relier cet appel a une session DomOS, executer les tools au bon endroit, survivre aux pannes testees et fournir assez d'observabilite pour diagnostiquer le systeme sans exposer de secret. Toute case historique non cochee mais deja implementee doit etre corrigee dans la documentation au lieu de generer du travail en doublon.
+Le sprint est termine lorsqu'une personne peut cloner le depot, construire une image DomOS Server, deployer le serveur derriere HTTPS/WSS, brancher LiveKit Cloud ou self-hosted, configurer le domaine du widget, puis valider une conversation texte et audio depuis un navigateur public sans exposer de secret. La telephonie SIP reste explicitement hors scope tant qu'un besoin produit distinct n'est pas valide.

From ecf2f92e35990781517859bb5635a0859ba65347 Mon Sep 17 00:00:00 2001
From: Bgk Injector SqLi <81836350+borisbob91@users.noreply.github.com>
Date: Mon, 13 Jul 2026 02:54:07 +0000
Subject: [PATCH 3/7] feat(deploy): add production packaging and LiveKit web
 guide

---
 .dockerignore                                 |  14 ++
 apps/demo-server/Dockerfile                   |  43 ++++++
 .../content/docs/livekit/web-deployment.mdx   | 139 ++++++++++++++++++
 compose.yaml                                  |  63 ++++++++
 deploy/.env.example                           |  22 +++
 deploy/Caddyfile                              |  39 +++++
 6 files changed, 320 insertions(+)
 create mode 100644 .dockerignore
 create mode 100644 apps/demo-server/Dockerfile
 create mode 100644 apps/docs-site/src/content/docs/livekit/web-deployment.mdx
 create mode 100644 compose.yaml
 create mode 100644 deploy/.env.example
 create mode 100644 deploy/Caddyfile

diff --git a/.dockerignore b/.dockerignore
new file mode 100644
index 0000000..0e1b1da
--- /dev/null
+++ b/.dockerignore
@@ -0,0 +1,14 @@
+**/node_modules
+**/dist
+**/.turbo
+**/.astro
+.git
+.github
+.env
+.env.*
+!.env.example
+*.log
+coverage
+archives
+rapport
+sprints
diff --git a/apps/demo-server/Dockerfile b/apps/demo-server/Dockerfile
new file mode 100644
index 0000000..15b7258
--- /dev/null
+++ b/apps/demo-server/Dockerfile
@@ -0,0 +1,43 @@
+# syntax=docker/dockerfile:1.7
+
+FROM node:20-alpine AS base
+ENV PNPM_HOME=/pnpm
+ENV PATH=$PNPM_HOME:$PATH
+RUN corepack enable && corepack prepare pnpm@9.15.9 --activate
+WORKDIR /app
+
+FROM base AS deps
+COPY package.json pnpm-lock.yaml pnpm-workspace.yaml turbo.json tsconfig.base.json ./
+COPY apps/demo-server/package.json apps/demo-server/package.json
+COPY packages/core/package.json packages/core/package.json
+COPY packages/server/package.json packages/server/package.json
+COPY packages/adapter-livekit/package.json packages/adapter-livekit/package.json
+COPY packages/adapter-google/package.json packages/adapter-google/package.json
+COPY packages/adapter-openai/package.json packages/adapter-openai/package.json
+COPY packages/adapter-anthropic/package.json packages/adapter-anthropic/package.json
+COPY packages/audio/package.json packages/audio/package.json
+RUN pnpm install --frozen-lockfile
+
+FROM deps AS builder
+COPY apps/demo-server apps/demo-server
+COPY packages/core packages/core
+COPY packages/server packages/server
+COPY packages/adapter-livekit packages/adapter-livekit
+COPY packages/adapter-google packages/adapter-google
+COPY packages/adapter-openai packages/adapter-openai
+COPY packages/adapter-anthropic packages/adapter-anthropic
+COPY packages/audio packages/audio
+RUN pnpm --filter @domos/demo-server... build
+RUN pnpm deploy --filter @domos/demo-server --prod /prod/demo-server
+
+FROM node:20-alpine AS runtime
+ENV NODE_ENV=production
+ENV PORT=4001
+WORKDIR /app
+RUN addgroup -S domos && adduser -S domos -G domos
+COPY --from=builder --chown=domos:domos /prod/demo-server ./
+USER domos
+EXPOSE 4001
+HEALTHCHECK --interval=30s --timeout=4s --start-period=15s --retries=3 \
+  CMD node -e "const n=require('node:net');const s=n.connect(Number(process.env.PORT||4001),'127.0.0.1',()=>{s.end();process.exit(0)});s.setTimeout(3000,()=>process.exit(1));s.on('error',()=>process.exit(1))"
+CMD ["node", "dist/server.js"]
diff --git a/apps/docs-site/src/content/docs/livekit/web-deployment.mdx b/apps/docs-site/src/content/docs/livekit/web-deployment.mdx
new file mode 100644
index 0000000..53f9fa4
--- /dev/null
+++ b/apps/docs-site/src/content/docs/livekit/web-deployment.mdx
@@ -0,0 +1,139 @@
+---
+title: Déployer DomOS avec LiveKit
+description: Mise en production du serveur, du widget web et du canal audio LiveKit.
+---
+
+# Déployer DomOS avec LiveKit
+
+DomOS utilise **deux canaux complémentaires**. ADTP transporte la session, le contexte, les tools et les approvals. LiveKit transporte l'audio temps réel du navigateur. Couper LiveKit ne doit donc pas supprimer la conversation texte.
+
+## Architecture cible
+
+```text
+Navigateur HTTPS
+  ├─ Widget DomOS ── WSS ───────────────┐
+  └─ livekit-client ── WebRTC ───────┐  │
+                                      │  │
+                              LiveKit Cloud
+                              ou self-hosted
+                                         │
+Internet ── TLS/Caddy ── DomOS Server ───┘
+                         ├─ ADTP /domos
+                         └─ POST /domos/livekit/token
+```
+
+Les valeurs `LIVEKIT_API_KEY`, `LIVEKIT_API_SECRET` et `GOOGLE_API_KEY` restent dans le serveur. Le navigateur reçoit uniquement un token de room court, après validation de l'API key DomOS et de la session.
+
+## Choisir votre LiveKit
+
+| Option | À choisir quand | Ce que vous gérez |
+| --- | --- | --- |
+| LiveKit Cloud | premier déploiement, petite équipe | projet, région, clés et quotas |
+| Self-hosted | contrainte réseau, souveraineté ou contrôle infra | TLS, TURN, UDP/TCP, Redis, montée en charge et supervision |
+
+Pour un premier environnement public, **LiveKit Cloud est le meilleur choix**. L'auto-hébergement ajoute beaucoup d'exploitation sans améliorer le widget.
+
+## 1. Préparer les variables
+
+Copiez l'exemple sans le committer :
+
+```bash
+cp deploy/.env.example .env
+```
+
+Renseignez au minimum :
+
+```ini
+DOMOS_DOMAIN=api.example.com
+DOMOS_LIVEKIT_ALLOWED_ORIGINS=https://app.example.com
+LIVEKIT_URL=wss://your-project.livekit.cloud
+LIVEKIT_API_KEY=...
+LIVEKIT_API_SECRET=...
+GOOGLE_API_KEY=...
+ADMIN_PASSWORD=...
+```
+
+`DOMOS_LIVEKIT_ALLOWED_ORIGINS` contient l'origine exacte du site qui héberge le widget. N'utilisez pas `*` en production.
+
+## 2. Construire et lancer
+
+Sans reverse proxy, utile pour vérifier localement :
+
+```bash
+docker compose build server
+docker compose up -d server
+docker compose ps
+```
+
+Avec HTTPS automatique via Caddy :
+
+```bash
+docker compose --profile proxy up -d --build
+```
+
+Le DNS de `DOMOS_DOMAIN` doit pointer vers la machine avant le démarrage de Caddy. Les ports 80 et 443 doivent être accessibles publiquement.
+
+## 3. Configurer le widget
+
+Le canal DomOS doit viser le WebSocket public :
+
+```ini
+VITE_DOMOS_ENDPOINT=wss://api.example.com/domos
+VITE_DOMOS_LIVEKIT_TOKEN_ENDPOINT=https://api.example.com/domos/livekit/token
+```
+
+Le widget ouvre d'abord une session DomOS. Une fois le `sessionId` disponible, `useDomOSLiveKitRoom` demande un token puis rejoint la room. Les tools continuent à passer par ADTP.
+
+## 4. Vérifier le parcours
+
+Effectuez ces contrôles dans l'ordre :
+
+1. `docker compose ps` indique que `server` est healthy.
+2. Le widget ouvre son WebSocket en `wss://`.
+3. Une session DomOS est créée avec une API key valide.
+4. `POST /domos/livekit/token` retourne un token pour cette session.
+5. Le navigateur demande l'autorisation microphone.
+6. La room passe à l'état connecté.
+7. L'audio utilisateur est publié.
+8. Un tool DomOS s'exécute via ADTP.
+9. Couper LiveKit laisse le chat texte utilisable.
+
+## 5. Lire les erreurs rapidement
+
+| Symptôme | Cause probable | Vérification |
+| --- | --- | --- |
+| `origin_not_allowed` | origine du widget absente | valeur exacte de `DOMOS_LIVEKIT_ALLOWED_ORIGINS` |
+| `livekit_not_configured` | variable LiveKit manquante | les trois variables `LIVEKIT_*` côté serveur |
+| room bloquée en connexion | URL, TURN ou réseau | console navigateur et région LiveKit |
+| microphone silencieux | permission refusée ou piste mute | permission du site et état `muteMicrophone` |
+| chat indisponible aussi | panne ADTP, pas LiveKit | connexion WSS DomOS et API key |
+
+## 6. Sécurité production
+
+- Servez le widget et DomOS uniquement en HTTPS/WSS.
+- Restreignez les origines du token endpoint.
+- Gardez les tokens de room courts.
+- Faites tourner le conteneur en utilisateur non-root.
+- Placez les secrets dans le gestionnaire de secrets de votre plateforme.
+- Ne loggez jamais les tokens, le contexte brut, les arguments ou résultats de tools.
+- Appliquez un rate limit au token endpoint au niveau proxy ou plateforme.
+
+## 7. Mise à jour et rollback
+
+Avant chaque mise à jour :
+
+```bash
+docker compose build server
+docker compose run --rm server node --version
+docker compose up -d server
+```
+
+Conservez le tag de l'image précédente dans `DOMOS_IMAGE_TAG`. Pour revenir en arrière, remettez ce tag puis relancez :
+
+```bash
+docker compose up -d --no-build server
+```
+
+## Limites actuelles
+
+Le dépôt fournit maintenant le packaging de référence. Il reste à valider l'image dans la CI, exécuter le smoke test depuis un vrai domaine, ajouter une readiness applicative plus fine et confirmer les navigateurs cibles. La téléphonie SIP n'est pas requise pour le widget web et reste hors scope.
diff --git a/compose.yaml b/compose.yaml
new file mode 100644
index 0000000..d76aa05
--- /dev/null
+++ b/compose.yaml
@@ -0,0 +1,63 @@
+name: domos
+
+services:
+  server:
+    build:
+      context: .
+      dockerfile: apps/demo-server/Dockerfile
+    image: domos-server:${DOMOS_IMAGE_TAG:-local}
+    restart: unless-stopped
+    init: true
+    environment:
+      NODE_ENV: production
+      PORT: 4001
+      DOMOS_REQUIRE_API_KEY: ${DOMOS_REQUIRE_API_KEY:-true}
+      DOMOS_LIVEKIT_ALLOWED_ORIGINS: ${DOMOS_LIVEKIT_ALLOWED_ORIGINS:-http://localhost:5173}
+      LIVEKIT_URL: ${LIVEKIT_URL:-}
+      LIVEKIT_API_KEY: ${LIVEKIT_API_KEY:-}
+      LIVEKIT_API_SECRET: ${LIVEKIT_API_SECRET:-}
+      GOOGLE_API_KEY: ${GOOGLE_API_KEY:-}
+      ADMIN_PASSWORD: ${ADMIN_PASSWORD:-}
+    expose:
+      - "4001"
+    ports:
+      - "${DOMOS_PORT:-4001}:4001"
+    healthcheck:
+      test:
+        - CMD
+        - node
+        - -e
+        - "const n=require('node:net');const s=n.connect(4001,'127.0.0.1',()=>{s.end();process.exit(0)});s.setTimeout(3000,()=>process.exit(1));s.on('error',()=>process.exit(1))"
+      interval: 30s
+      timeout: 4s
+      start_period: 15s
+      retries: 3
+    security_opt:
+      - no-new-privileges:true
+    cap_drop:
+      - ALL
+
+  proxy:
+    image: caddy:2.8-alpine
+    profiles: ["proxy"]
+    restart: unless-stopped
+    depends_on:
+      server:
+        condition: service_healthy
+    environment:
+      DOMOS_DOMAIN: ${DOMOS_DOMAIN:-localhost}
+      ACME_EMAIL: ${ACME_EMAIL:-}
+    ports:
+      - "80:80"
+      - "443:443"
+      - "443:443/udp"
+    volumes:
+      - ./deploy/Caddyfile:/etc/caddy/Caddyfile:ro
+      - caddy_data:/data
+      - caddy_config:/config
+    security_opt:
+      - no-new-privileges:true
+
+volumes:
+  caddy_data:
+  caddy_config:
diff --git a/deploy/.env.example b/deploy/.env.example
new file mode 100644
index 0000000..1a81880
--- /dev/null
+++ b/deploy/.env.example
@@ -0,0 +1,22 @@
+# Image et exposition locale
+DOMOS_IMAGE_TAG=local
+DOMOS_PORT=4001
+DOMOS_REQUIRE_API_KEY=true
+
+# Domaine public du serveur DomOS, sans https://
+DOMOS_DOMAIN=api.example.com
+ACME_EMAIL=ops@example.com
+
+# Origines web autorisees a demander un token LiveKit
+DOMOS_LIVEKIT_ALLOWED_ORIGINS=https://app.example.com
+
+# LiveKit Cloud ou instance self-hosted, secrets serveur uniquement
+LIVEKIT_URL=wss://your-project.livekit.cloud
+LIVEKIT_API_KEY=
+LIVEKIT_API_SECRET=
+
+# Provider realtime actuellement implemente
+GOOGLE_API_KEY=
+
+# Administration DomOS
+ADMIN_PASSWORD=
diff --git a/deploy/Caddyfile b/deploy/Caddyfile
new file mode 100644
index 0000000..97d0486
--- /dev/null
+++ b/deploy/Caddyfile
@@ -0,0 +1,39 @@
+{
+  email {$ACME_EMAIL}
+  admin off
+}
+
+{$DOMOS_DOMAIN:localhost} {
+  encode zstd gzip
+
+  @livekitToken path /domos/livekit/token
+  handle @livekitToken {
+    rate_limit {
+      zone livekit_token {
+        key {remote_host}
+        events 30
+        window 1m
+      }
+    }
+    reverse_proxy server:4001
+  }
+
+  handle {
+    reverse_proxy server:4001 {
+      transport http {
+        keepalive 2m
+      }
+    }
+  }
+
+  header {
+    -Server
+    X-Content-Type-Options nosniff
+    Referrer-Policy strict-origin-when-cross-origin
+  }
+
+  log {
+    output stdout
+    format json
+  }
+}

From 97c0abf5c3cc5acb65cf3e4e45fc95765d9532fe Mon Sep 17 00:00:00 2001
From: Bgk Injector SqLi <81836350+borisbob91@users.noreply.github.com>
Date: Mon, 13 Jul 2026 02:54:20 +0000
Subject: [PATCH 4/7] fix(deploy): keep Caddy config compatible with official
 image

---
 deploy/Caddyfile | 20 +++-----------------
 1 file changed, 3 insertions(+), 17 deletions(-)

diff --git a/deploy/Caddyfile b/deploy/Caddyfile
index 97d0486..6c9df91 100644
--- a/deploy/Caddyfile
+++ b/deploy/Caddyfile
@@ -6,23 +6,9 @@
 {$DOMOS_DOMAIN:localhost} {
   encode zstd gzip
 
-  @livekitToken path /domos/livekit/token
-  handle @livekitToken {
-    rate_limit {
-      zone livekit_token {
-        key {remote_host}
-        events 30
-        window 1m
-      }
-    }
-    reverse_proxy server:4001
-  }
-
-  handle {
-    reverse_proxy server:4001 {
-      transport http {
-        keepalive 2m
-      }
+  reverse_proxy server:4001 {
+    transport http {
+      keepalive 2m
     }
   }
 

From dae4edfe8bd84c9f98909bc299a6ba9973c27bd4 Mon Sep 17 00:00:00 2001
From: Bgk Injector SqLi <81836350+borisbob91@users.noreply.github.com>
Date: Mon, 13 Jul 2026 03:00:41 +0000
Subject: [PATCH 5/7] docs(livekit): record LK09 implementation progress

---
 .../livekit/progress/SPRINT-LK-09-progress.md | 101 ++++++++++++++++++
 1 file changed, 101 insertions(+)
 create mode 100644 sprints/livekit/progress/SPRINT-LK-09-progress.md

diff --git a/sprints/livekit/progress/SPRINT-LK-09-progress.md b/sprints/livekit/progress/SPRINT-LK-09-progress.md
new file mode 100644
index 0000000..6b7024f
--- /dev/null
+++ b/sprints/livekit/progress/SPRINT-LK-09-progress.md
@@ -0,0 +1,101 @@
+# Sprint LK-09 progress - Deploiement web LiveKit
+
+Date de mise a jour : 2026-07-13
+Branche : `docs/sprint-lk09-production-hardening`
+Sprint : `sprints/livekit/SPRINT-LK-09-production-hardening.md`
+Statut : **en cours - implementation poussee, validation runtime non terminee**
+
+## Note importante
+
+LK-09 cible DomOS comme widget dans une page web. LiveKit transporte le media temps reel du navigateur, tandis qu'ADTP reste responsable de la session, du Shadow Context, des tools, des approvals et des resultats.
+
+La telephonie SIP a ete retiree du scope. Elle ne doit pas etre implementee sans besoin produit distinct valide.
+
+## Livre sur la branche
+
+- [x] Sprint LK-09 recentre sur le deploiement web.
+- [x] Dockerfile multi-stage pour `apps/demo-server`.
+- [x] Image runtime Node 20 avec utilisateur non-root.
+- [x] Healthcheck conteneur TCP initial.
+- [x] `.dockerignore` sans secrets ni artefacts locaux.
+- [x] `compose.yaml` pour DomOS Server.
+- [x] Profil proxy Caddy optionnel.
+- [x] Configuration HTTPS/WSS de reference.
+- [x] Exemple `deploy/.env.example` sans valeur secrete.
+- [x] Documentation LiveKit Cloud et self-hosted.
+- [x] Documentation du parcours widget -> session DomOS -> token -> room LiveKit.
+- [x] Documentation du fallback texte lorsque LiveKit est indisponible.
+- [x] PR #5 convertie en draft d'implementation.
+
+## Partiellement termine
+
+- [~] Healthcheck : le port TCP est teste, mais il manque une liveness et une readiness applicatives.
+- [~] Reverse proxy : configuration de reference ajoutee, mais pas encore testee sur un domaine public.
+- [~] Deploiement LiveKit : Cloud et self-hosted sont documentes, mais aucun environnement reel n'a encore ete valide.
+- [~] Securite production : non-root, CORS et secrets serveur sont couverts; rate limiting et verification d'image restent a valider sur la plateforme cible.
+- [~] Runbook : lancement et rollback sont documentes; restauration, incident et rotation des secrets doivent etre testes.
+
+## Reste a faire avant merge
+
+### Validation locale obligatoire
+
+- [ ] Executer `pnpm install --frozen-lockfile`.
+- [ ] Executer `pnpm --filter @domos/demo-server build`.
+- [ ] Executer les builds/tests de `@domos/core`, `@domos/server`, `@domos/adapter-livekit`, `@domos/react` et `@domos/ui`.
+- [ ] Executer `docker build -f apps/demo-server/Dockerfile .`.
+- [ ] Executer `docker compose config`.
+- [ ] Executer `docker compose up -d server` et verifier l'etat healthy.
+- [ ] Verifier que l'image demarre sans variables LiveKit.
+- [ ] Verifier que l'image demarre avec les trois variables `LIVEKIT_*`.
+- [ ] Verifier l'arret propre via `SIGTERM`.
+
+### Runtime production
+
+- [ ] Ajouter un endpoint liveness applicatif.
+- [ ] Ajouter un endpoint readiness distinguant DomOS `ready`, LiveKit `disabled`, `ready` ou `degraded`.
+- [ ] Ajouter ou confirmer une commande `start` production stable dans `apps/demo-server/package.json`.
+- [ ] Valider que le Dockerfile execute l'artefact reel genere par le build.
+- [ ] Ajouter une validation de configuration production : URL TLS, origines CORS et variables obligatoires.
+- [ ] Ajouter une politique de rate limiting compatible avec le proxy choisi ou la plateforme cible.
+
+### Validation sur domaine public
+
+- [ ] Pointer un domaine DNS vers le serveur.
+- [ ] Obtenir et renouveler un certificat TLS.
+- [ ] Connecter le widget en `wss://` a DomOS.
+- [ ] Appeler `/domos/livekit/token` depuis l'origine autorisee.
+- [ ] Rejoindre une room LiveKit depuis le navigateur.
+- [ ] Autoriser le microphone et publier l'audio.
+- [ ] Recevoir une reponse agent texte ou audio.
+- [ ] Executer un tool via ADTP pendant que LiveKit transporte l'audio.
+- [ ] Couper LiveKit et confirmer que le chat texte reste actif.
+- [ ] Tester Chrome, Firefox et au moins un navigateur mobile.
+
+### Lacunes SDK conservees dans LK-09
+
+- [ ] Definir le contrat de `DomOSClient.send()` sans transport ouvert.
+- [ ] Ajouter le test WebRTC complet `DataChannel.open -> HANDSHAKE_INIT -> HANDSHAKE_ACK`.
+- [ ] Ajouter dans DevTools la comparaison tools locaux / tools serveur / surface effective.
+
+## Risques connus
+
+1. L'image Docker n'est pas consideree valide tant que son build et son demarrage n'ont pas ete executes.
+2. Un port ouvert ne prouve pas que DomOS est pret a creer des sessions.
+3. Le proxy de reference ne remplace pas la validation des timeouts et WebSockets de la plateforme finale.
+4. LiveKit self-hosted demande TURN, ports UDP/TCP, TLS, supervision et eventuellement Redis; LiveKit Cloud reste recommande pour le premier deploiement.
+5. Aucun secret ne doit etre place dans le bundle widget, les logs, le dashboard ou les metadata LiveKit.
+
+## Gate de passage en ready for review
+
+La PR #5 peut quitter le statut draft uniquement lorsque :
+
+- [ ] l'image Docker build et demarre ;
+- [ ] Compose est valide ;
+- [ ] les builds/tests touches passent ;
+- [ ] liveness/readiness sont finalisees ;
+- [ ] le parcours public widget + LiveKit est prouve, ou explicitement reporte avec un environnement de staging planifie ;
+- [ ] aucun secret n'apparait dans l'image, les logs ou le frontend.
+
+## Prochaine action recommandee
+
+Commencer par la validation locale du packaging existant. Corriger d'abord tout echec du Dockerfile ou de `pnpm deploy`, puis ajouter liveness/readiness avant le smoke test public.

From ef34798625a1735d850dab7200c30e7efcf42204 Mon Sep 17 00:00:00 2001
From: Bgk Injector SqLi <81836350+borisbob91@users.noreply.github.com>
Date: Mon, 13 Jul 2026 03:07:59 +0000
Subject: [PATCH 6/7] feat(deploy): add self-hosted LiveKit compose profile

---
 compose.yaml                        | 45 ++++++++++++++++++
 deploy/.env.example                 | 16 +++++--
 deploy/Caddyfile                    | 20 +++++---
 deploy/livekit.yaml                 | 18 ++++++++
 docs/livekit/self-hosted-compose.md | 72 +++++++++++++++++++++++++++++
 5 files changed, 159 insertions(+), 12 deletions(-)
 create mode 100644 deploy/livekit.yaml
 create mode 100644 docs/livekit/self-hosted-compose.md

diff --git a/compose.yaml b/compose.yaml
index d76aa05..890ff92 100644
--- a/compose.yaml
+++ b/compose.yaml
@@ -37,6 +37,49 @@ services:
     cap_drop:
       - ALL
 
+  redis:
+    image: redis:7-alpine
+    profiles: ["livekit-selfhosted"]
+    restart: unless-stopped
+    command: ["redis-server", "--appendonly", "yes", "--requirepass", "${LIVEKIT_REDIS_PASSWORD}"]
+    volumes:
+      - livekit_redis_data:/data
+    healthcheck:
+      test: ["CMD-SHELL", "redis-cli -a \"$$LIVEKIT_REDIS_PASSWORD\" ping | grep PONG"]
+      interval: 10s
+      timeout: 5s
+      retries: 5
+    environment:
+      LIVEKIT_REDIS_PASSWORD: ${LIVEKIT_REDIS_PASSWORD}
+    security_opt:
+      - no-new-privileges:true
+
+  livekit:
+    image: livekit/livekit-server:${LIVEKIT_SERVER_TAG:-v1.9.6}
+    profiles: ["livekit-selfhosted"]
+    restart: unless-stopped
+    command: ["--config", "/etc/livekit.yaml"]
+    depends_on:
+      redis:
+        condition: service_healthy
+    environment:
+      LIVEKIT_KEYS: "${LIVEKIT_API_KEY}: ${LIVEKIT_API_SECRET}"
+      LIVEKIT_REDIS_PASSWORD: ${LIVEKIT_REDIS_PASSWORD}
+    volumes:
+      - ./deploy/livekit.yaml:/etc/livekit.yaml:ro
+    ports:
+      - "${LIVEKIT_HTTP_PORT:-7880}:7880/tcp"
+      - "${LIVEKIT_RTC_TCP_PORT:-7881}:7881/tcp"
+      - "${LIVEKIT_RTC_UDP_PORT:-7882}:7882/udp"
+    healthcheck:
+      test: ["CMD", "wget", "--spider", "-q", "http://127.0.0.1:7880/"]
+      interval: 15s
+      timeout: 5s
+      start_period: 15s
+      retries: 5
+    security_opt:
+      - no-new-privileges:true
+
   proxy:
     image: caddy:2.8-alpine
     profiles: ["proxy"]
@@ -46,6 +89,7 @@ services:
         condition: service_healthy
     environment:
       DOMOS_DOMAIN: ${DOMOS_DOMAIN:-localhost}
+      LIVEKIT_DOMAIN: ${LIVEKIT_DOMAIN:-livekit.localhost}
       ACME_EMAIL: ${ACME_EMAIL:-}
     ports:
       - "80:80"
@@ -61,3 +105,4 @@ services:
 volumes:
   caddy_data:
   caddy_config:
+  livekit_redis_data:
diff --git a/deploy/.env.example b/deploy/.env.example
index 1a81880..f2eb600 100644
--- a/deploy/.env.example
+++ b/deploy/.env.example
@@ -3,17 +3,23 @@ DOMOS_IMAGE_TAG=local
 DOMOS_PORT=4001
 DOMOS_REQUIRE_API_KEY=true
 
-# Domaine public du serveur DomOS, sans https://
+# Domaines publics, sans https://
 DOMOS_DOMAIN=api.example.com
+LIVEKIT_DOMAIN=livekit.example.com
 ACME_EMAIL=ops@example.com
 
 # Origines web autorisees a demander un token LiveKit
 DOMOS_LIVEKIT_ALLOWED_ORIGINS=https://app.example.com
 
-# LiveKit Cloud ou instance self-hosted, secrets serveur uniquement
-LIVEKIT_URL=wss://your-project.livekit.cloud
-LIVEKIT_API_KEY=
-LIVEKIT_API_SECRET=
+# LiveKit Cloud ou profil Compose self-hosted
+LIVEKIT_URL=wss://livekit.example.com
+LIVEKIT_API_KEY=replace-with-a-long-random-key
+LIVEKIT_API_SECRET=replace-with-a-long-random-secret
+LIVEKIT_SERVER_TAG=v1.9.6
+LIVEKIT_HTTP_PORT=7880
+LIVEKIT_RTC_TCP_PORT=7881
+LIVEKIT_RTC_UDP_PORT=7882
+LIVEKIT_REDIS_PASSWORD=replace-with-a-long-random-password
 
 # Provider realtime actuellement implemente
 GOOGLE_API_KEY=
diff --git a/deploy/Caddyfile b/deploy/Caddyfile
index 6c9df91..5fafb97 100644
--- a/deploy/Caddyfile
+++ b/deploy/Caddyfile
@@ -5,19 +5,25 @@
 
 {$DOMOS_DOMAIN:localhost} {
   encode zstd gzip
-
-  reverse_proxy server:4001 {
-    transport http {
-      keepalive 2m
-    }
-  }
-
+  reverse_proxy server:4001
   header {
     -Server
     X-Content-Type-Options nosniff
     Referrer-Policy strict-origin-when-cross-origin
   }
+  log {
+    output stdout
+    format json
+  }
+}
 
+{$LIVEKIT_DOMAIN:livekit.localhost} {
+  encode zstd gzip
+  reverse_proxy livekit:7880
+  header {
+    -Server
+    X-Content-Type-Options nosniff
+  }
   log {
     output stdout
     format json
diff --git a/deploy/livekit.yaml b/deploy/livekit.yaml
new file mode 100644
index 0000000..c0c5661
--- /dev/null
+++ b/deploy/livekit.yaml
@@ -0,0 +1,18 @@
+# LiveKit single-node reference for the `livekit-selfhosted` Compose profile.
+# API keys are injected through LIVEKIT_KEYS and never stored in this file.
+port: 7880
+log_level: info
+
+rtc:
+  tcp_port: 7881
+  udp_port: 7882
+  use_external_ip: true
+
+redis:
+  address: redis:6379
+  password: "${LIVEKIT_REDIS_PASSWORD}"
+
+room:
+  auto_create: true
+  empty_timeout: 300
+  departure_timeout: 20
diff --git a/docs/livekit/self-hosted-compose.md b/docs/livekit/self-hosted-compose.md
new file mode 100644
index 0000000..abf2601
--- /dev/null
+++ b/docs/livekit/self-hosted-compose.md
@@ -0,0 +1,72 @@
+# LiveKit self-hosted avec Docker Compose
+
+Ce profil fournit une reference **single-node** pour le widget web DomOS. Il lance DomOS Server, LiveKit Server et Redis. Il ne contient ni SIP, ni ingress/egress, ni cluster multi-node.
+
+## Prerequis
+
+- deux domaines DNS : `api.example.com` pour DomOS et `livekit.example.com` pour LiveKit ;
+- ports publics `80/tcp`, `443/tcp`, `443/udp`, `7881/tcp` et `7882/udp` ;
+- une adresse IP publique joignable par LiveKit ;
+- Docker Engine avec Compose v2.
+
+Le proxy Caddy termine TLS pour les APIs HTTP/WebSocket. Les medias WebRTC utilisent directement `7881/tcp` et `7882/udp`. Le proxy HTTP ne remplace pas ces ports RTC.
+
+## Configuration
+
+```bash
+cp deploy/.env.example .env
+```
+
+Generez des valeurs longues et aleatoires pour :
+
+```ini
+LIVEKIT_API_KEY=...
+LIVEKIT_API_SECRET=...
+LIVEKIT_REDIS_PASSWORD=...
+```
+
+Gardez `LIVEKIT_URL=wss://livekit.example.com`. Les memes key/secret sont utilises par DomOS pour signer les tokens et par LiveKit pour les verifier.
+
+## Demarrage
+
+```bash
+docker compose --profile livekit-selfhosted --profile proxy config
+docker compose --profile livekit-selfhosted --profile proxy up -d --build
+docker compose ps
+```
+
+Sans Caddy, pour un test local uniquement :
+
+```bash
+docker compose --profile livekit-selfhosted up -d --build
+```
+
+## Pare-feu
+
+Ouvrez :
+
+- `80/tcp` et `443/tcp` pour TLS ;
+- `443/udp` pour HTTP/3 de Caddy, optionnel ;
+- `7881/tcp` pour le fallback RTC/TCP ;
+- `7882/udp` pour le media WebRTC single-node.
+
+N'exposez pas Redis. Pour un deploiement distribue, remplacez le port UDP unique par une plage RTC et utilisez la topologie officielle LiveKit.
+
+## Verification
+
+1. `https://api.example.com` atteint DomOS.
+2. `wss://api.example.com/domos` ouvre la session ADTP.
+3. `https://livekit.example.com` atteint l'API LiveKit.
+4. Le token endpoint DomOS retourne `livekitUrl: wss://livekit.example.com`.
+5. Le widget rejoint une room et publie le microphone.
+6. Couper `livekit` laisse le chat texte DomOS actif.
+
+## Limites de cette reference
+
+- single-node uniquement ;
+- pas de TURN/TLS integre dans LiveKit ; pour les reseaux restrictifs, ajoutez un TURN public correctement configure ;
+- pas de SIP, ingress ou egress ;
+- pas de haute disponibilite Redis ;
+- la validation sur un domaine public reste obligatoire avant production.
+
+Pour une premiere mise en ligne, LiveKit Cloud reste plus simple. Ce profil self-hosted sert lorsque le controle de l'infrastructure est un besoin explicite.

From 7a6a00ad2ac8706af109ff3e59868d71af2e42f7 Mon Sep 17 00:00:00 2001
From: Bgk Injector SqLi <81836350+borisbob91@users.noreply.github.com>
Date: Mon, 13 Jul 2026 03:08:25 +0000
Subject: [PATCH 7/7] fix(deploy): pin current LiveKit release and simplify
 container checks

---
 compose.yaml        | 8 +-------
 deploy/.env.example | 3 ++-
 2 files changed, 3 insertions(+), 8 deletions(-)

diff --git a/compose.yaml b/compose.yaml
index 890ff92..777a49f 100644
--- a/compose.yaml
+++ b/compose.yaml
@@ -55,7 +55,7 @@ services:
       - no-new-privileges:true
 
   livekit:
-    image: livekit/livekit-server:${LIVEKIT_SERVER_TAG:-v1.9.6}
+    image: livekit/livekit-server:${LIVEKIT_SERVER_TAG:-v1.13.1}
     profiles: ["livekit-selfhosted"]
     restart: unless-stopped
     command: ["--config", "/etc/livekit.yaml"]
@@ -71,12 +71,6 @@ services:
       - "${LIVEKIT_HTTP_PORT:-7880}:7880/tcp"
       - "${LIVEKIT_RTC_TCP_PORT:-7881}:7881/tcp"
       - "${LIVEKIT_RTC_UDP_PORT:-7882}:7882/udp"
-    healthcheck:
-      test: ["CMD", "wget", "--spider", "-q", "http://127.0.0.1:7880/"]
-      interval: 15s
-      timeout: 5s
-      start_period: 15s
-      retries: 5
     security_opt:
       - no-new-privileges:true
 
diff --git a/deploy/.env.example b/deploy/.env.example
index f2eb600..b27c2c3 100644
--- a/deploy/.env.example
+++ b/deploy/.env.example
@@ -15,7 +15,8 @@ DOMOS_LIVEKIT_ALLOWED_ORIGINS=https://app.example.com
 LIVEKIT_URL=wss://livekit.example.com
 LIVEKIT_API_KEY=replace-with-a-long-random-key
 LIVEKIT_API_SECRET=replace-with-a-long-random-secret
-LIVEKIT_SERVER_TAG=v1.9.6
+# Version stable verifiee le 2026-07-13. Mettre a jour volontairement apres lecture des release notes.
+LIVEKIT_SERVER_TAG=v1.13.1
 LIVEKIT_HTTP_PORT=7880
 LIVEKIT_RTC_TCP_PORT=7881
 LIVEKIT_RTC_UDP_PORT=7882