Arguments de lancement

Les applis et widgets lisent les valeurs nommées dans kapp.arguments. Le type du trigger n’invente pas des champs amount, viewers ou tier. Déclarer une entrée et fournir sa valeur sont deux étapes différentes.

Configuration et valeur runtime

Contexte	Déclaration
Appli	Configuration trigger_arguments, ou contrat kind qui prime sur elle. Les clés sont explicites.
Widget	Éditeur d’arguments ; identifiant dérivé du nom, par exemple « Pseudo cible » → pseudo-cible. Le blueprint IA n’expose qu’un sous-ensemble des options.
Trigger dynamique V2	Schéma d’arguments propre au trigger ; ne pas le confondre avec les arguments initiaux de l’appli.

Type	Valeur attendue et précautions
Player	Le SDK hydrate un User à partir des données reçues. Une saisie login doit désigner un viewer accessible ; cet argument n’est pas une preuve de l’identité de l’appelant.
int	Conversion entière ; une chaîne invalide peut devenir zéro. Contrôler les bornes métier.
bool	Booléen ; textes reconnus : yes/true/oui/on/1 et no/false/non/off/0. Une valeur non reconnue est refusée si requise, sinon peut devenir null.
string, long_string, tts_input	Texte ; aucune conversion automatique en montant décimal.
string_list	Tableau de strings nettoyées ; un tableau structuré est préférable à une chaîne à découper.

kapp.arguments['pseudo-cible'] utilise l’identifiant réel. Les clés internes _raw et _config ne sont pas des arguments métier à déclarer. La présence de Player dans un schéma de service ne garantit pas la même hydratation que les arguments de lancement.

Chaque source a son parsing

• Appel kapp.apps : fournir un objet avec les clés déclarées ; string_list accepte un tableau, les entrées vides sont éliminées. Les clés non déclarées ne sont pas un canal de données libre.
• Commande chat / saisie de récompense : les tokens entre guillemets conservent leurs espaces ; long_string et tts_input non cités peuvent absorber la fin. string_list utilise le séparateur déclaré, virgule par défaut. Ce parsing n’est pas une garantie sur les métadonnées d’un événement Twitch.
• Formulaire dashboard : les valeurs sont produites par les champs du formulaire, puis validées au lancement ; ce n’est pas un test du parsing chat.

Les sept types du runtime ne sont pas tous exposés par chaque éditeur. En particulier le blueprint widgets accepte actuellement six types, sans string_list ni son séparateur ; préserver ces configurations via l’éditeur adapté. Les widgets n’ont pas de fichier de configuration d’appli à créer.

Pour la cible et le résultat, lire lanceurs. Pour un widget, read_sdk_doc {service: "anatomy"} décrit la structure ; pour une appli, app-to-app décrit le manifeste et les fichiers. Une donnée absente doit être traitée avant tout effet métier.