Skip to main content
Youka est conçu pour être piloté par des agents. Chaque commande de la CLI renvoie une enveloppe JSON lisible par machine, chaque écriture prend en charge des clés d’idempotence, et l’API publique expose la même surface avec la même sémantique. Cette page rassemble les règles d’exploitation dont un auteur d’agent a besoin avant de connecter Youka à un workflow.

Bien démarrer

Si vous configurez un agent pour la première fois, installez d’abord la CLI Youka, puis installez la skill karaoke Youka :
Cela fournit à l’agent une skill Youka prête à l’emploi, adossée à la CLI. Une fois installée, utilisez les patterns de workflow ci-dessous pour créer des vidéos de karaoké, personnaliser le style et exporter des fichiers MP4 en toute sécurité.

Donnez une consigne à votre agent

Après avoir installé la CLI et la skill, vous pouvez donner à votre agent une tâche directe comme celle-ci :

Règles d’exploitation

Toujours utiliser --json

Dans la CLI, passez toujours --json. Dans l’API, définissez toujours Accept: application/json. Ne parsez jamais la sortie destinée aux humains.

Toujours envoyer une clé d’idempotence

Chaque écriture doit inclure une clé d’idempotence stable, afin que les relances après un timeout renvoient le résultat d’origine au lieu de dupliquer le travail.

Relire l’état durable

Ne faites pas confiance à des réponses de mutation potentiellement obsolètes. Après une tâche terminale, relisez le projet ou l’export pour obtenir l’état final.

Sonder avec backoff

Commencez avec un intervalle de 2–3 secondes. Appliquez un backoff exponentiel pour les traitements longs. Respectez les réponses 429.

Contrat de sortie

Chaque commande de la CLI en mode --json écrit exactement une enveloppe sur stdout. Succès :
Échec :
Codes de sortie :

Workflow de bout en bout

Le workflow canonique d’un agent est : créer un projet, attendre, exporter, télécharger le résultat. Voici le pattern complet avec des implémentations CLI et SDK.

Conseils de polling

La plupart des écritures renvoient des handles d’opération dans le SDK. Préférez client.projects.wait(...) et client.exports.wait(...), et ne descendez vers client.tasks.* que lorsque vous avez explicitement besoin d’un accès bas niveau aux tâches. Dans la CLI, --wait gère le polling pour vous. Dans le SDK, les helpers d’attente utilisent un intervalle de 2 s par défaut et acceptent pollIntervalMs.
Respectez les réponses 429. En cas de rate limit, appliquez un backoff d’au moins la valeur de l’en-tête Retry-After (ou 30 s s’il est absent).

Clés d’idempotence

Chaque opération de création et de mise à jour prend en charge une clé d’idempotence. Règles :
  • Utilisez une clé stable, unique, déterministe par mutation logique. Bien : create-song-${sourceHash}. Mauvais : un nouvel UUID à chaque relance.
  • Réutilisez la même clé lors des relances. Le serveur reconnaît la relecture et renvoie le résultat d’origine.
  • Les clés sont limitées au compte et expirent après 24 heures.
  • Si le serveur renvoie IDEMPOTENT_REPLAY_IN_PROGRESS (HTTP 202), la requête d’origine est encore en cours. Attendez et relancez avec la même clé.
Pattern d’exemple :
Voir API idempotency pour le contrat complet.

Récupération d’erreurs

Branchez en fonction de error.code et error.retryable. Les cas courants :

Découvrir les champs modifiables

Avant de modifier des presets, récupérez le schéma de preset afin que le modèle connaisse les champs valides et les types de valeurs :
Pour les paramètres de projet, préférez lire d’abord les paramètres actuels du projet, puis soumettre un body de mise à jour minimal via youka project settings <id> --body .... Récupérez-le une fois par session d’agent et mettez le résultat en cache.

Agents en parallèle

Lorsque plusieurs agents s’exécutent en concurrence sur le même compte :
  • Scopez les clés d’idempotence à la fois à l’identité de l’agent et à la mutation logique : agent-${agentId}-create-${sourceHash}. Cela évite qu’une relance d’un agent entre en collision avec une nouvelle requête d’un autre agent.
  • Gardez les lectures sans limite — les requêtes GET sont peu coûteuses et sans effets de bord.
  • Utilisez une seule file pour POST /projects/{projectId}/exports par projet si vous avez besoin d’un historique d’exports ordonné. Sinon, les exports peuvent arriver dans le désordre.

Et ensuite