Sistema de ativos do mecanismo v1 + polimento de bate-papo profundo
Um impulso 24 horas por dia em quatro trilhas paralelas: o mecanismo recebeu um sistema de ativos adequado, a renderização aumentou um padrão de qualidade de "paridade de pixel" bloqueado no CI, a sandbox permitiu ao agente "ver" se a imagem está correta, o painel de bate-papo precisou de cem passes de polimento, o backend realizou testes pesados em torno de segurança e contratos, e um grande refator finalmente tornou o hot-reload da interface independente.
Quatro faixas num dia: o panorama do dia
Este foi o dia mais denso até agora, indo da meia-noite até a manhã seguinte com quatro pistas rodando ao mesmo tempo: o recurso de pouso do motor após recurso e correção sob um loop fechado estrito de sete etapas, o painel de bate-papo entrando em estado estacionário "nunca concluído" polonês, o backend pregando a segurança e os contratos de interface com testes um por um, além de um refator de fechamento que retirou o recarregamento a quente da interface por conta própria. Reunir tantas coisas em um dia sem caos se resumia a duas coisas: cada faixa tinha limites e critérios de aceitação claros, e quanto mais próxima uma mudança estivesse da fundação, mais ela teria que ser verificável. Abaixo está dividido por tema, mas lembre-se que eles avançaram juntos em um único dia.
Sistema de ativos do mecanismo v1: referenciando o conteúdo do jogo por identificador
A entrega mais importante do motor neste dia foi a primeira versão de um sistema de ativos. Antes disso, o “conteúdo do jogo”, como modelos, texturas e cenas, não tinha uma forma unificada de ser gerenciado; o sistema de ativos deu-lhes uma identidade formal: cada ativo é um objeto estruturado referenciado através de um “identificador” leve, em vez de transmitir enormes dados brutos. Uma alça é como um número de telefone de uma biblioteca: segure-a e você poderá pegar o livro, sem carregá-lo inteiro. Uma cena de sala de amostra foi construída para validar a cadeia. O significado: o conteúdo do jogo agora pode ser referenciado, compartilhado e reutilizado de forma estruturada, com um ponto de entrada para carregar modelos, texturas e cenas. É o verdadeiro ponto de partida para todos os recursos posteriores de “importar um modelo, colocar ativos em uma cena”.
Uma referência de paridade de pixels: a qualidade da renderização não pode regredir silenciosamente
O que um renderizador interno mais teme não é um único quadro errado, mas "piorar silenciosamente sem que ninguém perceba" - mude uma coisa e alguns quadros diferem da referência em alguns pixels, invisíveis aos olhos, mas desaparecendo com o tempo. Este dia levantou um critério de “paridade de pixel”: compare os quadros renderizados do mecanismo com uma referência pixel por pixel, e no momento em que a diferença excede um limite, a integração contínua fica vermelha e impede que a mudança se funda no tronco. Acontece que "a renderização está correta" de algo observado manualmente e pelo tato em um portão automático e objetivo que é executado em cada commit. Para um mecanismo que evolui sua qualidade de imagem a longo prazo, esse portão é a pré-condição para que a qualidade se mantenha estável – com ele, você pode alterar a renderização com ousadia e sem medo.
Verificação visual do sandbox: deixe o agente “ver” se a imagem está correta
Ter uma IA editando jogos automaticamente se depara com um problema inevitável: depois de mudar as coisas, como ela sabe que a imagem está realmente certa? Verificar apenas se o código errou facilmente leva a "o código não travou, mas a tela está preta", embora acredite que foi bem-sucedido. Este dia construiu um mecanismo de verificação visual na sandbox, separando deliberadamente duas funções - “produzir a imagem” e “verificar a imagem”: um lado comanda o jogo e captura os frames, o outro julga os frames capturados. A separação das funções torna a verificação mais confiável - sem a armadilha de autocertificação do tipo "eu edito, faço captura de tela, declaro que está tudo bem". Essa etapa é fundamental para que o agente passe de "pode escrever código" para "é responsável por sua saída": ele não apenas joga código por cima da parede, mas pode fechar o ciclo e ver "como realmente se parece aquilo que fiz".
Renderização instanciada + muitos objetos: um jogo de blocos como pedra de toque
Este dia também aprimorou a capacidade de muitos objetos do motor com uma demonstração de minijogo de “limpeza de blocos em queda”. Esses jogos apresentam muitos blocos idênticos na tela ao mesmo tempo e emitem um comando de sorteio separado para cada pilha, aumentando o custo rapidamente. Para isso o motor adicionou “desenho instanciado”: um único envio desenha um grande lote do mesmo objeto, amortizando o custo repetido. O caminho de renderização de muitos objetos foi organizado ao lado, para que "muitas entidades aparecendo juntas" funcione de forma rápida e estável. Validar com um minijogo genuinamente jogável, em vez de um teste abstrato, é em si uma disciplina – fazer um jogo real funcionar sem problemas é muito mais convincente do que passar em um trecho isolado.
Cerca de 100 passes de chat-polonês: custo, duração, vários provedores
O painel de bate-papo entrou em estado estacionário “nunca concluído” neste dia, com mais de cem pequenas iterações focadas em algumas coisas práticas. Um: descubra o custo e a duração reais de cada turno, com um formato de valor adaptável – centavos, moedas de dez centavos, dólares cada um com a precisão correta – para que você veja rapidamente quanto custou. Dois: um seletor alternável para "qual back-end de codificação usar": você pode fixar uma conversa em uma, a escolha é lembrada, sincroniza entre guias, suporta seleção de teclado para cima/para baixo e avisa quando aquele que você escolheu não está disponível. Terceiro: tratamento cuidadoso do estado indutor de ansiedade "o modelo está pensando silenciosamente por um longo tempo" - mostrando os segundos decorridos, sugerindo uma mudança além de um limite e uma nota de espaço reservado para "concluído, mas sem saída visível". Cada passagem tocou em uma coisa, foi autotestada e registrou uma nota. Essa faixa ganha cem passagens porque é a superfície para a qual o usuário olha por mais tempo a cada dia: por mais forte que seja a capacidade, se a leitura for laboriosa e parecer incerta, não há confiança.
Segurança de back-end e fortalecimento de contratos: listas de permissões, defesa transversal, muitos testes
Como o agente realmente lê e grava arquivos em sua máquina, o back-end deve tornar "ele só pode tocar o que deveria" hermético. Este dia estabeleceu um grande lote de defesas e testes em torno da segurança de arquivos e caminhos: restringindo caminhos acessíveis com uma lista de permissões, adicionando defesa contra excesso de alcance de "travessia de diretório", recusando-se a substituir um diretório existente ao escrever um arquivo e redigindo o caminho inicial do usuário em respostas externas (para que os caminhos reais da sua máquina não vazem). Enquanto isso, os contratos de interface do back-end foram definidos teste por teste – qual entrada deveria retornar o quê, como os casos extremos são tratados, tudo protegido por testes, e a contagem de testes unitários ultrapassou um marco naquele dia. Nada disso é um “novo recurso visível”, mas decide se você ousa permitir que uma IA de edição de arquivos entre em seu próprio projeto: somente com limites claros, comportamento previsível e regressões detectadas por testes é que há verdadeira paz de espírito.
Um refator de fechamento: tornando independente o hot-reload da interface
Chegando de madrugada, o dia terminou com uma refatoração estrutural: tornando o mecanismo de recarga a quente da interface independente e colocando cada parte em seu lugar ao longo do caminho - os dados do jogo do usuário foram movidos para o próprio diretório da instância, a fonte do mecanismo extraída para um local de construção unificado, a configuração do ambiente elevada para a raiz do repositório e o layout do diretório aninhado propenso a armadilhas corrigido. Esse refatorador quase não mostra nenhuma alteração por parte do usuário, mas torna a experiência de “editar código, a interface recarrega instantaneamente” mais limpa e menos propensa a interferência cruzada. Quanto mais clara a base, mais rápido você constrói mais tarde — fazer isso no final do dia é justamente porque, depois de tantas coisas novas terem aparecido, toda a árvore precisava de uma consolidação para se realinhar.
O que este dia significa
Se os dias anteriores provaram que “a conversa pode construir algo executável”, este dia lançou as bases para “isso pode ser feito de forma confiável e de longo prazo”. O sistema de ativos permite que o conteúdo seja gerenciado estruturalmente; o benchmark de paridade de pixels e a verificação visual do sandbox fornecem um juiz objetivo de "a imagem está correta"; a segurança e os testes do back-end tornam confiável “deixar a IA agir”; o polimento do chat faz com que as pessoas queiram usá-lo diariamente; e o refatorador de fechamento mantém tudo limpo em termos de engenharia. Juntos, eles revelam uma postura: avançar rapidamente, mas deixar a cada passo um rastro sólido que pode ser verificado, regredido e retrospectivo. Esse é exatamente o modelo que este log quer deixar para o desenvolvimento futuro – velocidade e rigor não são um ou outro, mas duas coisas que podem ser alcançadas no mesmo dia.