Changements du SDK et du knowledge applis

2026-10-31 — Diagnostics communs au portail et au DEV HUB

• L’upload, la synchronisation et la soumission partagent les diagnostics du manifeste, des scopes, des fichiers référencés et des préférences. Un JSON/type/chemin invalide refuse l’enregistrement avant toute écriture ; une déclaration retirée ou une entrée manquante peut rester dans le brouillon mais empêche sa soumission. Les champs inconnus et ressources optionnelles manquantes produisent des avertissements. Voir livraison.
• Le HUB présente les diagnostics dans un panneau commun. « Vérifier mon app en ligne » et check_app contrôlent le brouillon déjà envoyé sans le soumettre ; push, transpile et get_app_status exposent le rapport. Les erreurs indiquent la correction et les opérations bloquées. Corriger les sources, reconstruire le runtime si nécessaire et renvoyer les fichiers suffit à actualiser les diagnostics.
• Les clients HUB précédents continuent de recevoir leurs champs d’erreur/avertissement historiques ; les versions publiées ne sont pas modifiées. Un retour à un backend antérieur retire les nouveaux contrôles et rend la vérification complète indisponible dans le HUB, sans annuler les corrections apportées aux apps.

2026-10-31 — Diagnostics avant soumission

• Le portail regroupe les erreurs bloquantes et les avertissements à chaque « Submit for validation », avec le fichier, le champ et la correction conseillée. Les contrôles utilisent les fichiers envoyés à Kappapps et s'appliquent aussi aux brouillons existants. Un refus laisse la version modifiable ; un avertissement seul permet la soumission. Voir livraison.
• launch-mode: backtask et la clé back-task (même false ou null) bloquent désormais la soumission. Les retirer et déclarer explicitement [{"type":"PROCESSUS"}] dans config/default_triggers.config.json si l'app doit démarrer automatiquement sur l'overlay. launch-mode: oneshot est signalé sans bloquer ; external reste accepté. Voir le manifeste.
• Les versions publiées et les installations existantes conservent leur comportement. Cette migration ne demande pas de changer de SDK ; revenir à un backend antérieur retire les contrôles de soumission sans réintroduire les déclarations supprimées.

2026-10-31 — Un cycle de vie commun aux applis

• Une appli démarre, reste ouverte jusqu'à sa fin ou son arrêt, et peut afficher du contenu. Les nouveaux manifestes ordinaires omettent launch-mode. Les anciens champs restent compatibles ; external conserve sa seule contrainte d'affichage.
• apps.run(), runApp(), les listes et runTarget acceptent aussi les anciennes backtasks compatibles avec l'overlay. Une surface incompatible renvoie unsupported_display_mode. Le timeout arrête l'attente, sans fermer la cible.
• Les déclencheurs restent configurables. Le PROCESSUS implicite des anciennes backtasks de contrat antérieur à 5 ne s'applique qu'à l'installation ou à la restauration explicite des defaults. Les mises à jour, relectures et réactivations préservent les déclencheurs existants.
• Les exemples, le bootstrap et le DEV HUB ne proposent plus de catégorie de durée de vie. Le JSON brut et les liens documentaires historiques sont conservés.

2026-10-30 — Sauvegarde explicite des médias générés

• textToSpeech.speech(), textToSpeech.generate(), ai.draw() et ai.sound() acceptent save (false par défaut) et un title obligatoire lorsque save: true. Le backend nomme le média slug-app — titre, avec l'identité authentifiée, et le conserve sept jours. Les widgets utilisent widget-ID. L'appli déclare file:write pour sauvegarder. Voir IA et TTS.
• Les appels existants continuent à retourner/jouer le résultat, disponible sept jours, mais ne l'ajoutent plus automatiquement aux médias du channel. Pour retrouver cet ajout, demander explicitement la sauvegarde. Un upload explicite conserve son fonctionnement ; retirer le réupload si la même génération passe à save: true.
• Cette option demande un backend et un SDK à jour. Déployer le backend avant le nouveau SDK ; un retour arrière doit conserver le backend capable de servir les fichiers temporaires encore valides. Les fichiers déjà présents ne sont ni renommés ni supprimés par cette évolution.

2026-10-30 — Consignes vocales libres et préparation TTS

• speech() et generate() acceptent translate_instructions et enhance_instructions, désactivées par défaut. L’amélioration inclut la traduction et prend priorité. Seuls les crochets existants changent ; les paroles restent identiques. moderate reste facultatif. Avec transformation, speech() attend la préparation validée, sans attendre l’audio ; generate() conserve son retour audio prêt.
• Les crochets sont désormais des consignes libres. Les raccourcis du streamer sont remplacés à leur emplacement ; le ton persistant et les alias d’émotions de Kappapps sont retirés des nouvelles demandes. Les anciens jobs restent lisibles. Pour un comportement explicite, employer des consignes courtes en anglais ou activer la traduction.
• Les segments sans paroles sont exclus. Sans paroles ni soundboard valide, la promesse rejette avec {status: 422, reason: 'tts_no_playable_content'} avant dépense. Les pistes non vocales des annonces retirent tous les blocs entre crochets. Adapter les captures d’erreurs et les mentions comme [VIP]. Voir le contrat TTS.
• L’appel avec booléen et le ciblage existant restent compatibles. Les nouvelles options nécessitent le SDK et le backend mis à jour ; un retour arrière nécessite leurs versions compatibles et la vidange préalable des nouveaux jobs.

2026-10-30 — Déclencheurs configurables pour les backtasks

• Les versions d'app créées sous le contrat 5 déclarent leurs déclencheurs d'installation dans config/default_triggers.config.json, y compris pour une backtask. Pour un démarrage automatique, déclarer [{"type":"PROCESSUS"}] ; [] est autorisé. Les anciennes versions de backtasks gardent leur processus implicite à l'installation, sans appliquer leur ancien fichier de defaults.
• Le streamer peut gérer les déclencheurs des apps oneshot et backtask de la même façon, et ajouter un PROCESSUS à ces deux modes. Les mises à jour et réactivations ne rétablissent plus les defaults supprimés ni les processus désactivés.
• Les defaults ne remplacent pas automatiquement les déclencheurs d'une installation existante. Le streamer peut les rétablir explicitement, avec confirmation, pour la version installée ; ses préférences et leurs déclencheurs sont conservés. Voir le contrat des modes et déclencheurs.

2026-10-27 — Génération et édition d’images

• kapp.ai.draw() utilise un même modèle pour la génération sans référence et l’édition avec références. Les signatures, scopes et URL de média restent identiques. Transmettre les URL de référence complètes, sans ajouter https: devant une URL qui commence déjà par https://. Voir common/reference/ai.md.
• Les routes /ai/leonardo/*, /ai/generator/v1 et /ai/advanced-generator/v1, absentes des méthodes IA du SDK V2, répondent désormais 410 (ai_endpoint_retired). La Promise HTTP du SDK est rejetée ; aucun fallback ni appel payant n'est effectué. Migrer vers kapp.ai.draw() pour les images et kapp.ai.generate() pour le JSON. Les données historiques restent stockées. Un retour aux anciens endpoints nécessite un retour arrière du backend et de sa configuration.

2026-10-18 — Créations successives de lecteurs YouTube

• kapp.youtube.embed() crée désormais un lecteur à chaque appel, même après le premier chargement ou lors d'appels simultanés. Le chargement de l'API est partagé par page et préserve un éventuel callback YouTube déjà installé.
• La Promise renvoie l'instance native du lecteur avec le type distribué YoutubePlayer. Utiliser onReady pour les commandes de lecture ; le retour de embed() n'attend pas cet événement. Une erreur ou un délai de chargement de 15 secondes rejette les appels en attente et permet un nouvel essai explicite. Voir reference/integrations.md.

2026-10-18 — Types des données du SDK

• Les déclarations distribuées décrivent maintenant les listes d'événements et les statistiques par participant de stream.getData(), les métadonnées YouTube et les champs du catalogue d'items. Le format des réponses reste identique.
• youtube.video() est typé avec null pour une vidéo indisponible ; playlistVideos() est une liste d'entrées, pas une réponse enveloppée. Les accès corrects sont illustrés dans reference/channel.md et reference/integrations.md.
• chat.twitch est accessible dans les types publiés. getSettings() décrit les champs lus ; setSettings() accepte les champs modifiables via ChatSettingsUpdate. Les appels existants aux items avec seulement {id} restent valides.

2026-10-18 — Noms des médias envoyés

• kapp.medias.upload(blob, name) conserve désormais le nom fourni, dans les applis comme dans les widgets, après validation commune avec le gestionnaire de fichiers. Sans nom, le SDK V2 à jour demande au serveur un nom unique pour chaque envoi.
• Les noms explicites peuvent être partagés par plusieurs fichiers ; un envoi crée un nouveau fichier et ne remplace pas l'existant. Choisir des noms distincts pour les recherches avec get(name). Les anciens SDK transmettent leur nom de fichier comme un nom fourni. Voir reference/medias.md.

2026-10-18 — Le booléen de blacklist est respecté

• user.setBlacklist(false) retire désormais le viewer de la blacklist Kappapps du channel. true, l'absence d'argument et undefined continuent à l'ajouter. removeBlacklist() reste disponible pour le retrait.
• Lors d'une mise à jour du SDK, vérifier les anciens appels avec false : ils ajoutaient le viewer à cause du bug et le retirent désormais. Utiliser true pour demander explicitement l'ajout. Voir reference/users.md.

2026-10-18 — Débannissement Twitch et permission de bannissement

• user.removeBan() et kapp.users.moderation.unban(login) utilisent désormais DELETE /ban/v1 avec moderation:ban, comme le bannissement. Les contrats de manifeste antérieurs à 4 restent exemptés ; les widgets ne déclarent pas de scopes.
• Une appli au contrat 4 qui utilisait ces méthodes avec seulement moderation:manage doit ajouter moderation:ban à infos.json.scopes. Les anciennes versions du SDK et les appels removeTimeout() / untimeout() gardent leur route et leur permission historiques.
• Le retrait d'un ban permanent fonctionne déjà dans le service commun, y compris sans timeout enregistré dans Kappapps. La route historique reste compatible. Les refus Twitch sont propagés ; l'état local n'est effacé qu'après succès. Voir reference/users.md.

2026-10-18 — Images IA et bannissement Twitch ouverts aux applis

• kapp.ai.draw() est accessible à toutes les applis avec le scope ai:draw, ainsi qu'aux widgets. La réserve IA et les limites du channel restent applicables ; les erreurs de permission ou de réserve rejettent la Promise.
• user.setBan() et kapp.users.moderation.ban() sont accessibles à toutes les applis avec moderation:ban. Il s'agit d'un ban définitif du chat Twitch ; les autorisations Twitch et les protections du viewer restent applicables. La route historique de modération avancée exige aussi ce scope lorsqu'elle applique un ban définitif (duration: null).
• Ces deux scopes sont exigés à partir du contrat de manifeste 4, attribué aux nouvelles versions d'appli. Les versions antérieures restent exemptées ; ajouter les scopes utilisés à infos.json.scopes lors de la prochaine nouvelle version. Les widgets ne déclarent pas de scopes.
• Le changement de rôle Kappapps (setRole() / users.role.set()) reste réservé aux applis officielles et aux widgets ; aucun nouveau scope ne l'ouvre aux applis tierces. Voir reference/ai.md et reference/users.md.

2026-10-17 — Variables du channel : lecture par préférence pour les applis

• Les applis disposent uniquement de variables.getFromPreference(path), en lecture seule sur une variable choisie par le streamer dans une préférence channelVariable. Le scope variables:read protège aussi la valeur hydratée dans les préférences. Les anciens scopes variables:write et variables:manage sont ignorés.
• Les applis utilisent les stockages V2 pour leurs données internes. get/set/create deviennent réservés aux widgets, avec un refus serveur 403 pour les appels d'applis, y compris anciennes.
• Les widgets conservent get() avec null sur 404, set() qui crée ou modifie et create() qui refuse l'existant. Le plafond est de 100 variables par channel ; modifier une valeur existante reste possible au plafond.
• Le modèle de namespace et de propriété par appli est abandonné, ainsi que le quota de 10 par appli. Les noms et valeurs existants sont conservés. Voir reference/variables.md pour le contrat et la migration des anciens appels.

2026-10-17 — Exceptions des services

• Avec le SDK V2 fournisseur et le Core corrigés, une exception du callback fait rejeter kapp.services.call() avec status et reason, au lieu de réussir avec {}. Traiter ce rejet avec try/catch ; une réponse métier volontaire {ok: false, reason} reste un résultat normal.
• Les succès et les réponses des anciens fournisseurs gardent leur format. L'ancien callService() du SDK V1 garde ses retours historiques ; les bundles V1 restent figés.
• Les versions mixtes restent compatibles : un ancien SDK fournisseur ou un ancien Core conserve l'ancien comportement d'erreur. Valider la réponse attendue et ne pas rejouer automatiquement une action après un échec. Voir reference/service-calls.md dans le knowledge téléchargé.

2026-10-13 — Confirmations facultatives et erreurs de relais

• Helper V3 3.0.0 : emitWithReply(event, data?, {timeoutMs?}) attend une réponse explicite de l'appli, avec corrélation et délai total borné. emit() reste disponible ; aucun ping automatique ni renvoi après timeout.
• SDK app V2 : les événements reçus exposent requestId et reply(data) uniquement pour ces demandes. L'appli valide et traite l'action avant de répondre. REPLY_TIMEOUT signifie résultat inconnu, jamais annulation ou échec certain.
• Les erreurs appli → plugins ne sont plus masquées en succès HTTP : PAYLOAD_TOO_LARGE (413) et RELAY_UNAVAILABLE (503) remontent au SDK, y compris lors d'une réponse. Ce correctif backend couvre les émissions existantes. Les helpers V1/V2 restent figés.
• Voir le contrat, les limites et l'exemple complet.

2026-10-13 — Helper V3 et stockages V2, migration coordonnée et volontaire

• Utiliser kapp.dataStorageV2, kapp.userDataStorageV2 et kapp.logsStorageV2 pour les nouveaux développements. Objets vides, clés numériques et listes conservent leur forme, même imbriqués. Les données viewers exigent un objet à la racine.
• Dans les plugins streamer et viewers, charger helper V3 3.0.0 depuis https://kappapps.app/assets/app-plugin/helper-v3.js. KappappsHost.data() lit les nouveaux stockages ; aucune méthode publique dataV2(). Migrer en même temps les écritures de l'appli vers les trois services V2.
• Le helper V2 est restauré et figé en 2.2.1 (initialisation corrigée, data() historique). Les anciennes API restent disponibles pendant l'adoption.
• En V3, les rejets sont des KappappsHostError à traiter par code : taille UTF-8 du corps JSON complet limitée à 16 384 octets inclus, file pleine, quotas, délais, réseau, relais et réponses invalides. Aucun relèvement des plafonds. Voir reference/plugins.md pour les délais et le retry 429 unique.
• Les pages hôtes streamer, viewers et preview signalent un helper V1/V2 identifié par un console.warn, une fois par plugin/version/page. Aucun changement dans les anciens helpers, aucune alerte visuelle ni transmission à l'overlay. Une version inconnue n'est pas considérée ancienne.
• Les anciennes méthodes, alias appUsersData / appHistorics et User.getAppData() / setAppData() restent disponibles mais dépréciés. Un warning client par méthode et par chargement rappelle le remplacement. Les anciens bundles figés sont couverts par des warnings serveur.
• Une copie V1 → V2 a lieu au premier appel V2, une fois par installation et famille. Aucun écrasement de la V1, aucune synchronisation ultérieure ; un reset V2 ne réimporte pas la V1.
• Ouvrir un brouillon ne migre rien. Le brouillon succède à la version précédente sur le channel développeur et retrouve le stockage de cette installation. Publier ne transfère pas les données du développeur aux streamers.
• L'inspecteur DEV HUB propose V1/V2 ; une simple consultation ne déclenche pas la copie.

Lire le contrat et le guide de migration, puis l'exemple de réparation idempotente. Les formes déjà perdues ne peuvent pas être devinées par la plateforme. Aucun retrait de V1 n'est programmé automatiquement.