Livrer une appli utilisable

La recette technique du workflow et le bootstrap préparent le runtime. Cette fiche couvre ce que le streamer et les viewers doivent recevoir. Distinguer les exigences du format, les recommandations de qualité et les options du produit ; une checklist documentaire ne constitue pas une validation du store.

Guides déclarés et utiles

Déclarer les chemins Markdown dans infos.json, puis inclure ces fichiers dans le runtime :

{
  "streamer-readme": "streamer.md",
  "viewers-readme": "viewers.md"
}

La plateforme lit la version installée, ou la version retenue pour la fiche publique. Un chemin absent, nul, invalide ou non Markdown ne fournit pas de guide ; déposer seulement streamer.md n’active rien. Les guides sont techniquement optionnels, mais recommandés pour toute appli qui demande une action ou une configuration. Remplacer les textes d’exemple avant livraison.

• Streamer : objectif, prérequis réels, installation, overlay/popout/plugins utilisés, configuration minimale, lancement, arrêt, récompenses, données conservées, limites et reprise après erreur.
• Viewers : accès, commandes ou boutons, règles, coûts éventuels, résultat et limites. Ne pas renvoyer vers les outils de développeur.
• Langues : décrire les langues réellement proposées. Les libellés/traductions suivent i18n ; *-readme désigne un fichier, pas une table de traductions. Un guide bilingue peut contenir deux sections clairement identifiées. Ne pas inventer streamer-readme.fr dans le manifeste.

Vignette, galerie et ressources

La présentation du catalogue se gère dans le portail développeur, onglet Présentation. Sa vignette personnalisée est prioritaire sur la vignette du runtime et peut changer sans nouvelle version d’appli. La galerie appartient à cette présentation ; ce n’est pas un tableau gallery à inventer dans infos.json.

À défaut de vignette personnalisée, la voie historique cherche le fichier déclaré par thumbnail, puis thumbnail.png, puis l’image de remplacement. Le bootstrap peut conserver thumbnail: null : ce n’est pas à lui de fournir l’identité visuelle de l’appli. Pour une vignette versionnée, déclarer un fichier réel et l’inclure dans le runtime.

L’éditeur de présentation accepte images JPEG/PNG/WebP, vidéos MP4 avec leur poster et liens YouTube pris en charge. Consulter les limites affichées de taille et de nombre ; ne pas confondre une miniature du catalogue, une capture de galerie et un asset utilisé pendant le jeu. Vérifier ordre, libellés, proportions et lisibilité aux petites tailles. Capturer les surfaces effectivement implémentées.

Les assets d’exécution doivent être copiés par le build et référencés avec leurs vrais chemins. public-assets déclare un dossier accessible via les mécanismes de la plateforme, distinct d’un répertoire public/ choisi par le bundler. Un plugin utilise KappappsHost.publicAssetsUrl après initialisation pour les assets partagés ; ne pas reconstruire une URL signée. Voir client plugin. Pour beaucoup d’images, réutiliser les atlas.

Recette avant soumission

Contrôle	Preuve attendue
Runtime autonome	Build puis six configurations ; aucune dépendance à un fichier source non livré.
Déclarations	Entrées, guides, plugins et ressources présents ; scopes nécessaires, formats réellement supportés.
Premier lancement	Paramètres vides/defaults, viewer ou média absent, chargement visible et erreur exploitable.
Surfaces	Overlay sans interaction souris, popout si déclarée, plugins dans leur shell Kappapps, formats annoncés.
Cycle de vie	Fin normale, arrêt volontaire, erreur, rechargement ; timers, listeners et lecteurs libérés.
Préférences et reprise	État initial appliqué, mise à jour, données préservées selon le contrat, upgrade si concerné.
Présentation	Guides lisibles, langues cohérentes, vignette et galerie représentatives, aucun placeholder livré.

Expliquer dans le compte rendu les versions servies, résultats, erreurs restantes et effets externes effectivement testés. Une simulation ne valide ni les sockets réels ni les autorisations Twitch. Respecter le périmètre demandé pour les appels externes et la publication.

push synchronise le brouillon selon les gardes du HUB ; la soumission/review/publication suit le parcours du portail. Une preview réussie ou un ZIP valide ne publie pas une version. Conserver le détail des changements et les données à préserver lors d’un upgrade. Une appli interactive ne devient pas utilisable dans OBS par le seul ajout de boutons.

Contrôles à la soumission

Le portail et le DEV HUB partagent les mêmes diagnostics lors de l’upload, de la synchronisation des configurations et de « Submit for validation ». Chaque problème indique sa gravité, son fichier, son champ, la correction attendue et les opérations bloquées.

Diagnostic	Envoi / synchronisation	Soumission
JSON invalide, mauvais type de champ, chemin interdit, structure de préférences inutilisable	Refus avant la première écriture ; fichiers précédents conservés	Refus
Déclaration retirée (back-task, scope retiré), scope inconnu, entrée nécessaire absente	Brouillon enregistrable, diagnostic visible	Refus
oneshot obsolète, champ inconnu, scope en double, média ou guide optionnel absent	Avertissement	Autorisée avec avertissement

Un ZIP décrit le runtime complet : ses fichiers absents ne sont pas récupérés dans l’ancienne version. Une synchronisation partielle contrôle les nouvelles configurations avec les fichiers en ligne conservés. Un envoi accepté peut donc afficher des erreurs qui bloquent uniquement la soumission. Corriger les sources, compiler si nécessaire, puis renvoyer les fichiers actualise le rapport.

Les contrôles couvrent les types et valeurs de infos.json, les scopes connus et retirés, app-index (index.html par défaut), le textset, les entrées des plugins et panneaux, les ressources déclarées et les préférences. Les entrées des plugins sont relatives à leur dossier déclaré. Les fichiers locaux exclus du push ne comptent pas comme présents. Les métadonnées inconnues sont signalées sans être interdites. prefs-panel peut servir uniquement les panneaux des WorkUnits, sans entrée globale prefs-panel-index.

« Vérifier mon app » dans le portail, « Vérifier mon app en ligne » dans le HUB et l’outil MCP check_app exécutent les contrôles complets du brouillon déjà envoyé, préférences et migrations de publication comprises. Ils n’envoient aucun fichier local, ne soumettent pas la version et ne modifient pas les installations. La soumission recontrôle toujours les fichiers actuels ; un ancien rapport ne permet pas de la contourner.

Les réponses API d’envoi et de synchronisation exposent validation : context, can_proceed (opération autorisée), can_submit et issues. Chaque issue porte code, severity, file, path, message, remediation et blocking (upload, sync, submit). Après un contrôle rapide, can_submit: null signifie que les contrôles complets restent à effectuer ; false signale déjà un obstacle. Seul un contrôle complet peut retourner true. Le HUB conserve le rapport dans get_app_status.local.validation et marque un résultat précédent comme obsolète si la prochaine opération échoue sans diagnostic.

Un contrôle indisponible bloque l’opération vérifiée et invite à réessayer. Ces règles s’appliquent aussi aux brouillons existants ; les versions déjà soumises ou publiées conservent leur comportement. Pour backtask, voir le manifeste.