Programmable V4 Hook Builder

Programme V4 Hook Builder

Utilisez le contrat machine public V3 pour transformer une révision exacte d'un projet en une demande de lancement déterministe. N'utilisez pas le Registry retiré ni le système de soumission GitHub. N'inférez pas que l'installation, la validation, la soumission, la diffusion par portefeuille, la finalité, l'indexation ou la vérification de la source exacte sont le même état.

Établir le contrat public actuel

Avant de modifier le projet ou de demander un secret :

1. Récupérez https://programmable.market/.well-known/programmable.json.
2. Suivez customLaunchApi.agentIntegration jusqu'au catalogue de remédiation annoncé, au schéma pack-config, au guide, au document OpenAPI, à la route des capacités et à la version immuable du CLI.
3. Vérifiez l'archive du CLI avec sa somme de contrôle publiée avant l'installation.
4. Récupérez sans authentification GET https://api.programmable.market/v3/capabilities.
5. Arrêtez-vous si l'ID de profil, la révision, la version, l'autorisation de production, les routes, les portées, la limite d'authentification ou la base de transfert de portefeuille diffèrent du contrat CLI installé. Ne jamais rétrograder ou improviser autour d'une dérive.

Le trafic CLI authentifié est fixé à l'origine exacte https://api.programmable.market. Il n'y a pas de remplacement d'origine. Les tests utilisent un transport injecté et ne redirigent jamais une clé API de production.

Lisez references/public-v3-contract.md avant d'éditer ou de soumettre un projet.

Construire le projet exact

Inspectez les instructions du dépôt et préservez le travail non lié. Épinglez une révision source publique contenant les octets soumis exacts. Construisez le graphe réel plutôt que d'adapter le projet à une architecture d'exemple.

Collectez et liez :

• nom du projet, symbole du jeton, description, une image exacte liée à la source, et des liens publics canoniques triés ;
• contenu source exact en Solidity Standard JSON et sortie du compilateur correspondante ;
• version complète de solc, paramètres d'optimisation et EVM, bibliothèques, ABI, bytecode de création/exécution, métadonnées, et arguments du constructeur ou de l'initialiseur ;
• chaque cible CREATE2 directe et arête de dépendance dans le graphe de lancement ;
• le masque de permissions réel du hook v4 et l'implémentation concrète atteignable pour chaque callback activé ;
• mode de financement, modèle de liquidité initiale, garde, chemin de retrait, preuve de verrouillage, frais LP, frais de projet, et la divulgation comptable requise de 10 points de base Programmable ;
• preuve pour chaque vérification revendiquée par la requête.

N'écrivez pas manuellement un digest, une adresse, un localisateur, une prédiction CREATE2, un engagement de graphe ou un hash de vérification. Le CLI les dérive à partir des fichiers exacts. Ne revendiquez pas une vérification réussie sans sa preuve sous-jacente.

Utiliser la machine à états déterministe

Le seul ordre de commandes est :

pack
validate --remote
submit
status --watch --until authorized
wallet
status --watch --until finalized

wallet n'est pas une commande CLI. C'est un arrêt pour que le contrôleur connecté inspecte et signe séparément le transfert exact du site web. Certains lancements EIP-3009 s'arrêtent d'abord à awaiting_funding_authorization ; ne signez que cette signature de données typées exacte dans le site web, interrogez à nouveau, puis arrêtez-vous séparément pour la transaction du Router à authorized.

Le CLI doit :

• lire la clé API uniquement depuis PROGRAMMABLE_API_KEY ou le magasin de secrets pris en charge par le système d'exploitation ;
• préserver les octets de requête identiques et la même clé d'idempotence durable (Idempotency-Key) lors des nouvelles tentatives ;
• honorer Retry-After sur 429 et 503 ;
• s'arrêter sur les états terminaux ;
• ne jamais demander de clé privée, signer ou diffuser.

L'admission statique de la source exacte côté serveur et la simulation finale du Router sont autoritaires pour l'admission au lancement. Les vérifications du packager local ou du modèle sont une préparation, pas la décision finale. Ne décrivez jamais l'une ou l'autre couche comme un audit ou une garantie de sécurité, de liquidité, de négociabilité, de résistance aux honeypots ou de comportement ultérieur des frais.

Gérer les résultats avec précision

• pending_review : continuez l'interrogation d'état de la ressource unique.
• action_required : lisez le constat typé et la remédiation ; modifiez la source exacte ou la preuve, puis créez un nouveau pack. Ne contournez pas le constat.
• awaiting_funding_authorization : arrêtez-vous pour le transfert de signature de financement exact du site web.
• authorized : arrêtez-vous pour que le contrôleur examine la chaîne, l'expéditeur, le Router, la valeur, le sélecteur, les données d'appel et les métadonnées.
• submitted : interrogez la même ressource ; un hash de transaction seul n'est pas la finalité.
• finalized : rapportez le lancement onchain séparément de l'indexation et de la vérification de la source exacte.
• failed ou cancelled : arrêtez-vous et rapportez le code d'erreur durable et l'ID de requête sans exposer la clé API.

Ne revendiquez jamais une compatibilité universelle des hooks. Le profil public prend en charge les graphes multi-contrats appartenant au projet et les quatorze bits de permission structurellement, mais la construction exacte peut encore être non prise en charge, nécessiter des preuves, échouer à la simulation ou nécessiter des modifications du projet. L'initialisation normale d'un pool n'ajoute pas de liquidité initiale ; la comptabilité personnalisée ou la liquidité amorcée par lancement doit être implémentée et divulguée par le projet.

Vérification et transfert

Exécutez des tests ciblés du projet, un pack déterministe, une validation locale, une pré-validation distante et git diff --check. Pour une répétition sans diffusion, arrêtez-vous avant submit. Pour une soumission réelle, donnez à l'utilisateur l'ID de requête, l'état durable actuel et l'URL de transfert de portefeuille sécurisé uniquement lorsque celle-ci est renvoyée par cette ressource exacte.

N'appelez pas le travail en direct à partir de vérifications locales, CI, d'une réponse préparée ou HTTP 200. Séparez la révision source, l'artefact CLI, l'admission serveur, l'action du portefeuille, la finalité onchain, la découverte/indexation et l'état du fournisseur de source exacte dans le transfert final.

Ressources réservées aux mainteneurs

references/eval-corpus.md est l'ensemble d'évaluation par trigger avant et adversarial pour les mainteneurs du skill ; ce n'est pas une instruction d'exécution. Les fichiers suivants appartiennent au système de soumission GitHub retiré et ne doivent pas être lus ni invoqués pour un lancement V3 : scripts/application-input-contract.mjs, scripts/autonomous-admission-contract.mjs, scripts/cli-runtime.mjs, scripts/github-exact-object-resolver.mjs, scripts/github-public-source-core.mjs, scripts/official-launchpad-core.mjs, scripts/package-dependency-contract.mjs, scripts/public-claims-core.mjs, scripts/review-target-contract.mjs, et scripts/submission-core.mjs.