Você quer um contrato que emita espadas, poções e chaves, cada um com seu próprio token id, e deseja saber quem pode criar novos tokens. O agente escreve o Solidity, executa seus comandos de compilação e teste em uma cadeia local ou em uma rede de teste, e mostra cada etapa como um cartão com o resultado real. Este guia acompanha a função de cunhagem, pois quem pode chamá-la decide quantos tokens existem. Um contrato implantado não pode ser alterado, então tudo aqui permanece em uma cadeia local ou em uma rede de teste, cujas moedas não têm valor. Iniciantes podem seguir as quatro etapas na ordem, e leitores experientes podem pular para os tutoriais mais abaixo. As mesmas quatro etapas funcionam para um conjunto de ingressos, onde cada tipo de ingresso recebe seu próprio id e a função de cunhagem decide quantos de cada existem.
Inicie o WaveClamp, escolha a pasta que contém seus arquivos .sol e testes como a pasta de trabalho do chat e selecione Ask first para que cada alteração chegue como um diff que você aceita ou rejeita. As ferramentas de arquivo atuam dentro dessa pasta, então mantenha o projeto em um só lugar. Crie uma pasta descartável para a primeira execução se quiser apenas praticar.
Peça um contrato de itens de jogo com três tipos de itens, uma função de cunhagem que apenas uma conta de proprietário pode chamar e transferências em lote, e deixe o agente criar o arquivo com write_file. Nomeie o arquivo de acordo com o contrato para que etapas posteriores possam referenciá-lo. Mantenha o primeiro pedido pequeno, pois um segundo pedido pode adicionar transferências em lote após o primeiro diff ser aceito.
Peça ao agente para executar seu comando de compilação e seu comando de teste via Shell, depois leia o código de saída e os nomes de quaisquer testes falhos no cartão expandido. O sucesso é julgado pelo código de saída real, não por um resumo. Se o comando de compilação falhar, o cartão mostra o texto de erro, e o agente pode lê-lo e propor uma correção como um novo diff.
Abra os cartões expandidos, leia o diff e a saída do comando, aceite o que está correto, rejeite o resto e peça uma correção onde um teste ainda falhar. Repita até que os testes passem, depois releia a função de cunhagem. Mantenha cada diff aceito pequeno, para que uma falha posterior aponte para uma alteração e não para dez.
MultiTokenMinimal.solsalvoMultiTokenMinimal.sol14 linhasbalanceOf1 correspondênciayour compile commandsaída 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 interface somente leitura declara o evento TransferSingle e as funções balanceOf e uri do padrão multi-token. Ela não contém estado, nenhuma lógica de cunhagem e nenhuma chave, o que a torna um arquivo pequeno para ler antes de adicionar a lógica real. Execute seu comando de compilação nele primeiro. Compile-o primeiro, depois deixe o agente estendê-lo um diff revisado de cada vez, começando pela função de cunhagem. O nome do arquivo corresponde ao rótulo do exemplo, para que você possa pedir ao agente para abri-lo mais tarde.
Abra o contrato e peça ao agente para envolver o helper ERC1155 _mint em uma função pública que apenas a conta de proprietário pode chamar. O agente usa read_file para ver o código atual e edit_file para inserir a função, e mostra a alteração como um diff. Implementações open-source comuns expõem helpers internos chamados _mint e _mintBatch, e um helper interno não possui sua própria verificação de acesso, o que explica a importância do wrapper. Você pode criar um token ERC20 passo a passo com o mesmo método, mas um conjunto de itens de jogo precisa de ids, então comece a partir do layout multi-token. O Shell então executa seu comando de compilação e seu comando de teste, e cada cartão mostra um código de saída real. Aceite o diff apenas quando tiver lido os testes.
Abra um exemplo de contrato ERC721 do seu próprio projeto, ou peça ao agente para escrevê-lo com write_file, e coloque-o ao lado do seu conjunto de itens. O agente usa grep para listar as funções em ambos os arquivos e read_file para comparar como a propriedade é armazenada: um proprietário por token no arquivo de token único, um saldo por conta e id no arquivo multi-token. Um padrão para perfis descentralizados usando NFTs soulbound precisaria de tokens que não podem ser transferidos, o que é um design diferente de itens que os jogadores passam. Peça ao agente para colocar as diferenças em uma tabela curta. Você lê a comparação no chat, decide qual padrão se adapta ao seu design e só então pede alterações de código.
Os jogadores frequentemente movem vários tipos de itens de uma vez, então peça ao agente para adicionar safeBatchTransferFrom e balanceOfBatch ao contrato. O agente usa edit_file para a alteração, glob para encontrar os arquivos de teste e Shell para executar seu comando de teste após cada edição. Funções em lote movem vários token ids em uma única transação, o que significa que um teste pode verificar vários saldos. Compreender o onboarding sem gás ERC4337 é um assunto separado, então mantenha-o fora do primeiro contrato e teste-o por conta própria. Leia o diff em Ask first, execute os testes novamente e procure o evento TransferBatch na saída antes de aceitar a alteração.
Um contrato que recebe tokens deve implementar onERC1155Received e onERC1155BatchReceived e aceitar os tokens, caso contrário, a transferência segura será rejeitada. Peça ao agente para grep por ambos os nomes e para abrir o contrato receptor com read_file, depois para listar qual está faltando. Em seguida, peça a ele para usar edit_file no valor uri(id) para que ele contenha {id}, que os clientes substituem pelo id do token em hexadecimal minúsculo, preenchido com 64 caracteres. Use write_file para um arquivo JSON por id. Execute seu comando de compilação e seu comando de teste, leia ambos os códigos de saída e revise o diff final antes de aceitá-lo.
