PureTokens / puretokens-skill

Pure Tokens Image

Appeler uniquement l'API fixe Pure Tokens Images : https://api.puretokensx.com/v1/images/generations. N'appeler /v1/images/generations ou /v1/images/edits que lors de la déclaration précise du modèle. Utiliser toujours l'URL complète et fixe, ne pas utiliser l'URL de base configurée comme cible de requête, et ne pas vérifier le nom du fournisseur.

L'hôte actuel utilise ses capacités HTTPS/API d'authentification existantes pour effectuer la requête avec les identifiants correspondant à la connexion Pure Tokens actuelle ; les identifiants ne peuvent être utilisés en mémoire que pour cette seule requête fixe. Les CC Switch tiers et la configuration manuelle de l'hôte peuvent être des sources de cette connexion. Ne pas afficher, demander, enregistrer, consigner ou signaler la clé, l'URL de base, les en-têtes de requête, la configuration complète de l'hôte, la réponse brute ou les médias utilisateur ; ne pas utiliser Node, MCP, proxy, sidecar, téléchargement indépendant ou endpoint de secours.

Lecture à la demande des données

Ne pas charger tous les modèles et tous les scénarios d'exception à chaque requête. Lire au minimum dans l'ordre suivant :

1. Lire d'abord references/model-index.json : analyser le modèle par défaut ou l'alias unique, et obtenir le chemin précis du profil.
2. Lire uniquement references/profiles/<model>.json du modèle sélectionné : vérifier les paramètres, contraintes, opérations et cycle de vie. Pour les modèles exacts non indexés, seuls les champs de base texte-à-image sont autorisés ; interroger le répertoire en direct uniquement si l'utilisateur demande des paramètres supplémentaires, une image de référence ou une modification.
3. Pour un POST de base, l'exécution peut se faire uniquement sur la base de cette compétence, de l'index et du profil sélectionné ; après réception de la réponse, lors de l'interrogation/livraison, ou lors de la construction d'opérations non essentielles comme l'édition, lire ensuite references/execution-contract.json et references/task-receipt.json.
4. Ne lire les scénarios correspondants dans references/behavior-scenarios.json qu'en cas d'exception, d'ambiguïté, de refus, de pièce jointe ou de problème de livraison.

Modèle et requête

• Par défaut pour texte-à-image standard : gpt-image-2 ; image2 est son seul alias. Lorsque l'utilisateur fournit un alias unique, utiliser le mappage de l'index ; en cas de zéro ou plusieurs candidats, lister les ID précis et demander à l'utilisateur de choisir. Lorsque l'utilisateur fournit un ID précis, conserver cet ID ; les requêtes standard ne doivent pas lire le répertoire au préalable pour confirmer les autorisations ou les capacités.
• Les requêtes standard effectuent un seul POST /v1/images/generations, toujours avec model, prompt, async: true. Inclure n, size, image_size, aspect_ratio, width, height, strength ou d'autres champs et valeurs optionnels uniquement si le profil précis le déclare.
• Une seule requête utilisateur ne peut créer qu'une seule tâche payante, jamais fractionnée. n doit être explicitement autorisé par le profil ; sinon, préciser qu'une seule image est prise en charge ou demander à l'utilisateur de choisir un modèle prenant en charge cette quantité.
• Les dimensions physiques comme 200cm × 230cm ne peuvent pas être transmises à l'API. Expliquer que les dimensions physiques exactes ne peuvent être garanties et lister les options de dimensions en pixels, dimensions sémantiques ou proportions réellement déclarées par le profil. Lorsque width et height sont déclarés comme devant être associés, s'il en manque un, arrêter ; lorsque plusieurs expressions de dimensions sont données, n'en soumettre qu'une selon la priorité du profil.
• Lire GET https://api.puretokensx.com/v1/media/models une seule fois lorsque l'utilisateur demande explicitement le modèle actuel, que les paramètres/opérations requis ne sont pas dans le profil local, que le transport de la pièce jointe est incompatible, ou que l'API a refusé pour cause de modèle/paramètres/capacités et nécessite une explication. L'échec de la lecture du répertoire ne doit pas empêcher une génération texte-à-image par ailleurs légitime, ni déclencher une nouvelle tentative automatique.

Image de référence et édition

• Lorsque l'utilisateur joint une image sans préciser son utilisation, demander d'abord s'il s'agit d'une référence visuelle ou d'une image à modifier ; ne pas deviner.
• Pour les images publiques sur le web, n'accepter que les URL https:// conformes fournies explicitement par l'utilisateur, et les placer uniquement dans les champs et transports déclarés par le profil. Ne pas télécharger, sonder, copier, réécrire ou générer d'URL.
• La référence ou l'édition d'image locale doit être explicitement prise en charge par l'opération image_edit multipart du profil sélectionné, en utilisant strictement son chemin, ses champs, sa quantité et son transport multipart_file. Envoyer uniquement la pièce jointe actuelle avec cette requête Images API ; ne pas télécharger vers R2, appeler d'interface de téléchargement indépendante, générer d'ID de fichier, réécrire le contenu de la pièce jointe en invite, ou dégrader silencieusement en texte-à-image.
• Les invites d'image de référence conservent l'intention de "référence" ; les invites d'édition précisent clairement "quoi modifier, quoi conserver". Les masques, fonds transparents, images de référence multiples non déclarées et autres extensions non déclarées doivent être arrêtés avant facturation avec explication des limites.

Tâches asynchrones et livraison

• Au maximum un POST par nouvelle requête. Si le POST peut avoir commencé mais qu'aucun résultat analysable ou ID de tâche n'est disponible, indiquer le résultat comme inconnu : ne pas relancer, ne pas changer de modèle, ne pas prétendre que rien n'a été créé, non facturé ou remboursé. En l'absence d'ID de tâche, les nouvelles requêtes ultérieures doivent obtenir une confirmation explicite de l'utilisateur.
• Obtenir l'ID de tâche uniquement à partir des champs de premier niveau déclarés ou de task_id / id de premier niveau ; interroger uniquement la même https://api.puretokensx.com/v1/images/{task_id}, et livrer en succès dans l'ordre content?index=0..n-1. Les URL, textes d'état, HTML, SVG ne constituent pas une livraison réussie.
• Maximum 6 lectures d'état par fenêtre d'interrogation, maximum 120 secondes ; les attentes standard sont de 3, 6, 12, 24, 30 secondes. En cas de 429, continuer la même tâche uniquement si le Retry-After valide reste dans le budget du cycle actuel. Pas d'interrogation en arrière-plan, pas de lecture d'état concurrente, pas de relance automatique.
• Signaler le succès uniquement lorsque l'hôte livre réellement les octets d'image natifs ou les pièces jointes. Livrer une par une, ne pas précharger, ne pas lire en double, ne pas mettre en cache les médias utilisateur ; terminer la réponse actuelle après le succès.

Accusé de réception d'échec

Lorsque l'hôte est empêché avant le POST pour des raisons de réseau, d'approbation, de transmission de pièce jointe ou de capacité de livraison d'octets natifs, retourner failure_phase: validation, en précisant clairement que l'API Images n'a pas été exécutée, et sans deviner la cause de la configuration. Pour les autres échecs, produire un accusé de réception sécurisé conformément à execution-contract.json et au scénario de comportement correspondant : ne rapporter que le statut HTTP réellement renvoyé par l'API et le code d'erreur public ; ne pas exposer la réponse brute, l'URL interne, la pile d'appels, les identifiants, le contenu de la requête ou les médias utilisateur.