Quieres un contrato que emita espadas, pociones y llaves, cada una con su propio token id, y quieres saber quién puede crear nuevos tokens. El agente escribe el Solidity, ejecuta tus comandos de compilación y prueba en una cadena local o en una red de prueba, y muestra cada paso como una tarjeta con el resultado real. Esta guía sigue la función de acuñación, porque quien pueda llamarla decide cuántos tokens existen. Un contrato desplegado no se puede cambiar, así que todo esto se queda en una cadena local o en una red de prueba, cuyas monedas no tienen valor. Los principiantes pueden seguir los cuatro pasos en orden, y los lectores experimentados pueden saltar a los recorridos más abajo. Los mismos cuatro pasos funcionan para un set de entradas, donde cada tipo de entrada obtiene su propio id y la función de acuñación decide cuántas de cada una existen.
Inicia WaveClamp, elige la carpeta que contiene tus archivos .sol y pruebas como la carpeta de trabajo del chat, y elige Ask first para que cada cambio llegue como un diff que aceptas o rechazas. Las herramientas de archivos funcionan dentro de esa carpeta, así que mantén el proyecto en un solo lugar. Crea una carpeta desechable para la primera ejecución si solo quieres practicar.
Pide un contrato de objetos de juego con tres tipos de objetos, una función de acuñación que solo una cuenta de propietario pueda llamar, y transferencias por lotes, y deja que el agente cree el archivo con write_file. Nombra el archivo según el contrato para que los pasos posteriores puedan referirse a él. Mantén la primera solicitud pequeña, porque una segunda solicitud puede añadir transferencias por lotes después de que se acepte el primer diff.
Dile al agente que ejecute tu comando de compilación y tu comando de prueba a través de Shell, luego lee el código de salida y los nombres de las pruebas fallidas en la tarjeta expandida. El éxito se juzga por el código de salida real, no por un resumen. Si el comando de compilación falla, la tarjeta muestra el texto del error, y el agente puede leerlo y proponer una corrección como un nuevo diff.
Abre las tarjetas expandidas, lee el diff y la salida del comando, acepta lo que está bien, rechaza el resto, y pide una corrección donde una prueba siga fallando. Repite hasta que las pruebas pasen, luego lee la función de acuñación una vez más. Mantén cada diff aceptado pequeño, para que un fallo posterior apunte a un cambio y no a diez.
MultiTokenMinimal.solguardadoMultiTokenMinimal.sol14 líneasbalanceOf1 coincidenciayour 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);
}Esta interfaz de solo lectura declara el evento TransferSingle y las funciones balanceOf y uri del estándar multi-token. No tiene estado, ni lógica de acuñación ni claves, lo que la convierte en un archivo pequeño para leer antes de añadir lógica real. Ejecuta tu comando de compilación en ella primero. Compílala primero, luego deja que el agente la extienda un diff revisado a la vez, empezando por la función de acuñación. El nombre del archivo coincide con la etiqueta del ejemplo, para que puedas pedirle al agente que lo abra más tarde.
Abre el contrato y pide al agente que envuelva el helper ERC1155 _mint en una función pública que solo la cuenta de propietario pueda llamar. El agente usa read_file para ver el código actual y edit_file para insertar la función, y muestra el cambio como un diff. Las implementaciones de código abierto comunes exponen helpers internos llamados _mint y _mintBatch, y un helper interno no tiene su propio control de acceso, por eso importa el wrapper. Puedes crear un token ERC20 paso a paso con el mismo método, pero un set de objetos de juego necesita ids, así que empieza desde la disposición multi-token. Shell luego ejecuta tu comando de compilación y tu comando de prueba, y cada tarjeta muestra un código de salida real. Acepta el diff solo cuando hayas leído las pruebas.
Abre un ejemplo de contrato ERC721 de tu propio proyecto, o pide al agente que lo escriba con write_file, y colócalo junto a tu set de objetos. El agente usa grep para listar las funciones en ambos archivos y read_file para comparar cómo se almacena la propiedad: un propietario por token en el archivo de token único, un saldo por cuenta e id en el archivo multi-token. Un estándar para perfiles descentralizados que use NFTs soulbound necesitaría tokens que no se puedan transferir, lo cual es un diseño diferente de los objetos que los jugadores intercambian. Pide al agente que ponga las diferencias en una tabla corta. Lees la comparación en el chat, decides qué estándar se adapta a tu diseño, y solo entonces pides cambios de código.
Los jugadores a menudo mueven varios tipos de objetos a la vez, así que pide al agente que añada safeBatchTransferFrom y balanceOfBatch al contrato. El agente usa edit_file para el cambio, glob para encontrar los archivos de prueba, y Shell para ejecutar tu comando de prueba después de cada edición. Las funciones por lotes mueven varios token ids en una transacción, lo que significa que una prueba puede verificar varios saldos. Entender el onboarding sin gas de ERC4337 es un tema separado, así que déjalo fuera del primer contrato y pruébalo por su cuenta. Lee el diff en Ask first, ejecuta las pruebas de nuevo, y busca el evento TransferBatch en la salida antes de aceptar el cambio.
Un contrato que recibe tokens debe implementar onERC1155Received y onERC1155BatchReceived y aceptar los tokens, de lo contrario la transferencia segura se rechaza. Pide al agente que grep por ambos nombres y que abra el contrato receptor con read_file, luego que liste cuál falta. Pídele luego que use edit_file en el valor uri(id) para que contenga {id}, que los clientes reemplazan con el token id en hexadecimal minúsculo, rellenado a 64 caracteres. Usa write_file para un archivo JSON por id. Ejecuta tu comando de compilación y tu comando de prueba, lee ambos códigos de salida, y revisa el diff final antes de aceptarlo.
