Lire la documentation LiveKit

Les SDK de LiveKit évoluent plus vite que les données d'entraînement des modèles, donc tout ce dont tu te souviens sur une API LiveKit, un flag CLI ou une valeur par défaut est une supposition. Les mauvaises suppositions coûtent du temps : un mauvais flag gaspille une exécution, une mauvaise signature gaspille une compilation.

Chaque fait spécifique à LiveKit que tu énonces ou que tu mets dans du code doit provenir d'une recherche dans cette session. Cela inclut les faits dont tu es confiant et les patterns que tu as vus dans d'autres repos.

Où chercher, par ordre de préférence

1. Le serveur MCP LiveKit Docs. Si ses outils sont dans ta session, utilise-les. C'est la même source que celle utilisée par la CLI, avec moins de friction.

2. lk docs. Disponible partout où la CLI LiveKit est installée, sans configuration MCP. Utilise-le quand les outils MCP ne sont pas disponibles ; n'arrête pas pour demander à l'utilisateur d'installer quelque chose en premier. Il peut chercher dans la documentation, récupérer des pages, chercher du code dans les repositories LiveKit, afficher le changelog récent d'un SDK, signaler la tarification et soumettre des retours. Commence par :

lk docs --help
lk docs search "agent simulations"

Une fois que la recherche t'a montré la bonne page, récupère-la. Il y a une sortie lisible par machine si tu préfères analyser plutôt que lire.

3. Recherche web sur docs.livekit.io. Uniquement quand aucune des deux options ci-dessus n'est disponible. Dis à l'utilisateur que tu as utilisé cette solution de secours et marque le code généré comme non vérifié.

Comment faire des recherches

• Cherche avant de lire. La recherche retourne des extraits par page, ce qui est généralement suffisant pour choisir la bonne page. Récupère des pages complètes uniquement une fois que tu sais laquelle tu as besoin, ou tu rempliras la context window avec des pages inutiles.
• Utilise la recherche de code pour le comment, la documentation pour le quoi. La documentation te dit qu'un paramètre existe. Les propres exemples de LiveKit montrent comment il est appelé. Quand une page de documentation et un exemple fonctionnel ne sont pas d'accord, va avec l'exemple et mentionne la divergence.
• Utilise le changelog pour les questions de version. « X est-il disponible maintenant », « quand Y a-t-il changé » et « pourquoi cet argument n'existe pas » sont répondus par le changelog, pas par la recherche.
• Vérifie la version sur laquelle tu es. Le SDK installé et la CLI déterminent ce qui fonctionne, et une fonctionnalité documentée peut ne pas exister dans la version installée. Pour toute commande CLI, --help sur le binaire installé prime sur toute autre source.

Signaler ce que tu as trouvé

• Cite la page quand une décision repose dessus, pour que l'utilisateur puisse te vérifier.
• Dis quand tu n'as pas pu vérifier quelque chose. « Je n'ai pas pu confirmer cette signature dans la documentation » est utile à l'utilisateur. Une supposition silencieuse ne l'est pas.
• Marque le code non vérifié. Si tu as dû écrire du code LiveKit sans recherche, ajoute un commentaire au site d'appel disant qu'il n'est pas vérifié, et dis-le dans ta réponse.
• N'invente pas un flag ou paramètre pour que l'exemple ait l'air complet. Un exemple incomplet avec une note est mieux qu'une fabrication plausible.

Quand la documentation est fausse

Parfois une page contredit la source du SDK ou le --help de la CLI. Quand ça arrive :

• Va avec ce qui fonctionne. --help, la source du SDK installé et un exemple fonctionnel prime sur une page en prose. Dis à l'utilisateur lequel tu as suivi et pourquoi.
• Signale-le avec la commande de retour de la documentation, et dis à l'utilisateur que tu l'as fait, pour que la prochaine personne ne rencontre pas la même erreur.

lk docs avertit parfois d'une asymétrie de version quand le serveur de documentation est un peu en avance sur la CLI. C'est normal et les résultats sont toujours bons. Suggère de mettre à jour lk et continue.

Compétences liées

• Construire un agent : building-livekit-agents
• Le tester en direct pendant le développement : debugging-livekit-agents
• Tests unitaires : testing-livekit-agents
• Simulations : writing-livekit-scenarios, running-livekit-simulations