Pour créer une dApp, commencez par un dossier ne contenant que le fichier ABI de votre propre contrat. Ouvrez ce dossier comme dossier de travail d'un nouveau chat, choisissez Ask first et décrivez la page que vous souhaitez : un bouton de connexion de portefeuille, un solde et une ligne de statut de transaction. L'agent cartographie le dossier, propose les fichiers sous forme de diffs et crée la page uniquement après votre acceptation de chaque modification. Décidez avant de commencer où le projet s'exécutera. Une chaîne locale sur votre propre PC convient bien à une première tentative, car les jetons qu'elle contient n'ont aucune valeur, et un réseau de test public est l'étape suivante une fois la page fonctionnelle. Utilisez des comptes jetables sur l'un ou l'autre, jamais un compte contenant des fonds réels, et gardez chaque clé privée et phrase de récupération hors du dossier, du chat et du dépôt. Le résultat est une petite page testée et un README qu'une autre personne pourrait suivre.
Choisissez le dossier du projet comme dossier de travail d'un nouveau chat et sélectionnez Ask first, afin que chaque modification écrivant un fichier attende votre décision. Placez le fichier ABI dans ce dossier avant de commencer.
Indiquez quelles données la page affiche et quels états de transaction elle doit gérer, en phrases simples. Nommez la fonction du contrat qu'elle appelle et le réseau auquel elle se connecte, par exemple votre chaîne locale.
Lisez chaque modification de fichier proposée dans le chat, puis acceptez-la ou rejetez-la avec une note courte. Développez une carte lorsque vous souhaitez voir le diff complet, et rejetez tout ce que vous ne pouvez pas expliquer en une phrase.
Laissez Shell exécuter votre commande de build et votre commande de test, et lisez le code de sortie sur chaque carte. Ouvrez la page contre la chaîne locale et comparez ce qu'elle affiche avec ce que vous attendez. Corrigez les échecs avant d'ajouter la fonctionnalité suivante.
balance-abi.jsonloadedapp.jssavedindex.html+4 lignesyour build commandexit 0[
{
"type": "function",
"name": "balanceOf",
"stateMutability": "view",
"inputs": [{ "type": "address", "name": "account" }],
"outputs": [{ "type": "uint256" }]
}
]Ce fragment JSON décrit une seule fonction en lecture seule, balanceOf, la fonction de lecture de solde utilisée par les jetons ERC-20. Elle prend une adresse nommée account et retourne un uint256. Un front-end utilise une ABI comme celle-ci pour appeler le contrat, et le fichier ne contient ni clé ni secret. Enregistrez-le sous balance-abi.json dans le dossier du projet, et remplacez-le par l'ABI complète de votre propre contrat une fois la page fonctionnelle, car un contrat réel possède généralement beaucoup plus de fonctions.
Une bonne façon de commencer à apprendre le web3 est de lire un petit fichier ABI avant d'écrire quoi que ce soit. Demandez à l'agent d'ouvrir balance-abi.json. read_file affiche le fichier, list_dir montre ce qu'il y a d'autre dans le dossier et grep confirme le nom exact de la fonction. L'agent explique ensuite dans le chat que balanceOf est une fonction view : elle lit des données et n'envoie aucune transaction, donc l'appeler ne change rien sur la chaîne. Rien n'est encore écrit. Il liste également ce dont la page aura besoin, à savoir une connexion à un nœud, l'adresse du contrat déployé et un compte à rechercher. Vérifiez chaque affirmation contre le JSON sur la carte, car un modèle peut mal lire un type ou nommer une fonction que le fichier ne contient pas, et demandez une correction avant de continuer.
Demandez une page qui lit le solde d'un compte de test jetable. write_file crée app.js avec un appel à votre chaîne locale via JSON-RPC, et edit_file ajoute une ligne de script à index.html. Vous n'avez besoin d'outils cross chain pour une dApp que lorsqu'elle communique avec plusieurs chaînes ; un premier projet sur une seule chaîne locale n'en a besoin d'aucun, donc laissez-les de côté. En mode Ask first, les deux modifications attendent sous forme de diffs. Lisez-les et acceptez-les. Shell exécute ensuite votre commande de build, et la carte affiche le vrai code de sortie. Ouvrez la page, comparez le nombre qu'elle affiche avec le nombre que votre chaîne locale rapporte pour le même compte, et demandez à l'agent de corriger la page si les deux diffèrent. Gardez l'adresse de la chaîne à un seul endroit, afin que changer de réseau plus tard signifie modifier une seule ligne.
Passer du web2 au web3 en tant que développeur consiste principalement à ajouter un portefeuille, un réseau et un état de transaction aux écrans que vous savez déjà construire. Demandez à l'agent d'ajouter une ligne de statut avec 5 états : non envoyé, en attente du portefeuille, en attente, confirmé et échoué. edit_file modifie le script et la feuille de style, et grep trouve tout endroit où un état manque encore. Le portefeuille signe ; votre code ne touche jamais à une clé privée ou à une phrase de récupération. Demandez également des messages pour un portefeuille manquant, le mauvais réseau et une signature rejetée, car un utilisateur réel les rencontrera tôt ou tard. Exécutez la page sur un réseau de test avec un compte jetable, rejetez une signature intentionnellement et vérifiez que l'état échoué apparaît avec un message clair.
Demandez à l'agent d'écrire un test front-end pour chaque état et un court README expliquant comment exécuter le projet. write_file crée les deux fichiers, Shell exécute votre commande de test et la carte rapporte le vrai code de sortie. Un développeur de dApps qui revient sur le projet un mois plus tard lira ce README en premier, alors vérifiez qu'il ne nomme que les commandes que vous utilisez réellement et qu'il indique quel réseau la page attend. Utilisez le mode Plan only en premier si vous voulez voir la liste des étapes avant qu'un fichier ne soit créé, puis passez à Ask first pour le mettre en œuvre. Lisez chaque diff, exécutez les tests vous-même une fois sur un réseau de test avec des comptes jetables, et gardez le README à côté du fichier ABI afin que les deux restent synchronisés.
