Vous voulez un seul contrat qui émet des épées, des potions et des clés, chacune avec son propre token id, et vous voulez savoir qui a le droit de créer de nouveaux tokens. L'agent écrit le Solidity, exécute vos commandes de compilation et de test sur une chaîne locale ou un réseau de test, et affiche chaque étape sous forme de carte avec le résultat réel. Ce guide suit la fonction de minting, car celui qui peut l'appeler décide du nombre de tokens existants. Un contrat déployé ne peut pas être modifié, donc tout ce qui suit reste sur une chaîne locale ou un réseau de test, dont les pièces n'ont aucune valeur. Les débutants peuvent suivre les quatre étapes dans l'ordre, et les lecteurs expérimentés peuvent passer directement aux parcours détaillés ci-dessous. Les quatre mêmes étapes fonctionnent pour un ensemble de billets, où chaque type de billet reçoit son propre id et où la fonction de minting décide du nombre de chaque type.
Démarrez WaveClamp, choisissez le dossier contenant vos fichiers .sol et vos tests comme dossier de travail du chat, et choisissez Ask first pour que chaque modification arrive sous forme de diff que vous acceptez ou rejetez. Les outils de fichiers fonctionnent dans ce dossier, alors gardez le projet à un seul endroit. Créez un dossier jetable pour la première exécution si vous voulez simplement vous entraîner.
Demandez un contrat d'objets de jeu avec trois types d'objets, une fonction de minting qu'un seul compte propriétaire peut appeler, et des transferts groupés, et laissez l'agent créer le fichier avec write_file. Nommez le fichier d'après le contrat afin que les étapes suivantes puissent y faire référence. Gardez la première demande petite, car une seconde demande peut ajouter des transferts groupés après que le premier diff ait été accepté.
Demandez à l'agent d'exécuter votre commande de compilation et votre commande de test via Shell, puis lisez le code de sortie et les noms des tests échoués sur la carte développée. Le succès est jugé par le code de sortie réel, et non par un résumé. Si la commande de compilation échoue, la carte affiche le texte d'erreur, et l'agent peut le lire et proposer une correction sous forme de nouveau diff.
Ouvrez les cartes développées, lisez le diff et la sortie de la commande, acceptez ce qui est correct, rejetez le reste, et demandez une correction là où un test échoue encore. Répétez jusqu'à ce que les tests réussissent, puis relisez la fonction de minting une dernière fois. Gardez chaque diff accepté petit, afin qu'un échec ultérieur pointe vers un seul changement et non vers dix.
MultiTokenMinimal.solsauvegardéMultiTokenMinimal.sol14 lignesbalanceOf1 correspondanceyour compile commandexit 0// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
interface IMultiTokenMinimal {
event TransferSingle(address indexed operator,
address indexed from, address indexed to,
uint256 id, uint256 value);
function balanceOf(address account, uint256 id)
external view returns (uint256);
function uri(uint256 id)
external view returns (string memory);
}Cette interface en lecture seule déclare l'événement TransferSingle et les fonctions balanceOf et uri de la norme multi-token. Elle ne contient aucun état, aucune logique de minting et aucune clé, ce qui en fait un petit fichier à lire avant d'ajouter la logique réelle. Exécutez d'abord votre commande de compilation dessus. Compilez-le d'abord, puis laissez l'agent l'étendre un diff revu à la fois, en commençant par la fonction de minting. Le nom du fichier correspond à l'étiquette de l'exemple, afin que vous puissiez demander à l'agent de l'ouvrir plus tard.
Ouvrez le contrat et demandez à l'agent d'entourer l'assistant ERC1155 _mint dans une fonction publique que seul le compte propriétaire peut appeler. L'agent utilise read_file pour voir le code actuel et edit_file pour insérer la fonction, et il affiche la modification sous forme de diff. Les implémentations open-source courantes exposent des assistants internes nommés _mint et _mintBatch, et un assistant interne n'a pas sa propre vérification d'accès, ce qui rend l'enveloppe importante. Vous pouvez créer un token ERC20 étape par étape avec la même méthode, mais un ensemble d'objets de jeu a besoin d'ids, alors commencez par la disposition multi-token. Shell exécute ensuite votre commande de compilation et votre commande de test, et chaque carte affiche un code de sortie réel. Acceptez le diff uniquement lorsque vous avez lu les tests.
Ouvrez un exemple de contrat ERC721 à partir de votre propre projet, ou demandez à l'agent d'en écrire un avec write_file, et placez-le à côté de votre ensemble d'objets. L'agent utilise grep pour lister les fonctions dans les deux fichiers et read_file pour comparer comment la propriété est stockée : un propriétaire par token dans le fichier à token unique, un solde par compte et id dans le fichier multi-token. Une norme pour les profils décentralisés utilisant des NFT soulbound nécessiterait des tokens non transférables, ce qui est un design différent de celui des objets que les joueurs s'échangent. Demandez à l'agent de mettre les différences dans un tableau court. Vous lisez la comparaison dans le chat, décidez quelle norme correspond à votre design, et seulement ensuite demandez des modifications de code.
Les joueurs déplacent souvent plusieurs types d'objets à la fois, alors demandez à l'agent d'ajouter safeBatchTransferFrom et balanceOfBatch au contrat. L'agent utilise edit_file pour la modification, glob pour trouver les fichiers de test, et Shell pour exécuter votre commande de test après chaque modification. Les fonctions batch déplacent plusieurs token ids en une seule transaction, ce qui signifie qu'un seul test peut vérifier plusieurs soldes. La compréhension de l'adoption sans gaz ERC4337 est un sujet à part, alors gardez-le hors du premier contrat et testez-le séparément. Lisez le diff dans Ask first, relancez les tests, et cherchez l'événement TransferBatch dans la sortie avant d'accepter la modification.
Un contrat qui reçoit des tokens doit implémenter onERC1155Received et onERC1155BatchReceived et accepter les tokens, sinon le transfert sécurisé sera rejeté. Demandez à l'agent de grep pour les deux noms et d'ouvrir le contrat de réception avec read_file, puis de lister lequel manque. Demandez-lui ensuite d'utiliser edit_file sur la valeur uri(id) pour qu'elle contienne {id}, que les clients remplacent par l'identifiant du token en hexadécimal minuscule, complété sur 64 caractères. Utilisez write_file pour un fichier JSON par id. Exécutez votre commande de compilation et votre commande de test, lisez les deux codes de sortie, et passez en revue le diff final avant de l'accepter.
