Angelicism001/isaackdb

Fluxo de trabalho de modding de Isaac

Nunca invente uma API do Binding of Isaac porque seu nome parece plausível. Um nome plausível não é evidência. Pesquise; se continuar ausente, diga NÃO VERIFICADO.

Roteie a tarefa

1. Inspecione o mod do usuário antes de editar: metadata.xml, main.lua, XML de conteúdo, includes, cópias de dependências e notas de alvo/versão.
2. Identifique a build alvo e se REPENTOGON/bibliotecas estão disponíveis. Se não especificado, use o pin do repositório apenas como base de pesquisa. Não afirme que o runtime instalado do usuário corresponde a esse pin ou é compatível com o futuro.
3. Traduza a solicitação em escopo, propriedade, tempo de vida, co-op, recursos, dependências, compatibilidade, desempenho e requisitos de teste. Para um chefe/personagem/fase ou sistema grande, escreva uma especificação curta primeiro. Se visuais mudarem, faça o inventário dos assets necessários e leia regras de produção gráfica. Crie arte apenas quando necessário; defina o contrato de folha/animação antes do trabalho final em PNG/ANM2.
4. Pesquise indexes/tasks.json, aliases, depois símbolos exatos. Leia knowledge/INDEX.md e o registro gerado com link para a fonte apenas para o domínio relevante.
5. Pesquise registros vanilla e REPENTOGON quando REPENTOGON estiver habilitado; seu registro de modificação explícito vence para esse alvo.
6. Verifique semântica de callback, precisão de versão, conflitos/problemas, viabilidade, co-op local, tempo de vida de estado, XML/recursos, desempenho e compatibilidade.
7. Escolha um padrão com rótulo de dependência. Distinga um scaffold de uma referência estática dourada; runtime_tested: false nunca significa verificado em gameplay.
8. Implemente a menor mudança compatível com a arquitetura. Reutilize módulos, IDs, callbacks, helpers e estilo existentes. Não crie um main.lua substituto antes de entender o projeto.
9. Execute python scripts/validate_kb.py --project <pasta-do-mod> --ecosystem <vanilla|repentogon> e as auditorias relevantes em prompts/.
10. Relate dependências, evidências exatas usadas, limites de validação e testes direcionados no jogo.

Quando a recuperação precisar de precisão:

• Pesquise indexes/symbols.json para APIs/enums/XML exatos.
• Pesquise indexes/callbacks.json para argumentos, filtros, retornos e modificações do REPENTOGON.
• Pesquise indexes/aliases.json para termos em linguagem natural.
• Pesquise indexes/errors.json para roteamento guiado por sintomas.
• Use knowledge/feasibility.md antes de trabalhos incomuns.
• Para semântica exata, leia o source_path do registro sob o checkout .cache/upstreams/<source>/ após verificar seu HEAD contra o pin do registro. Em caso de divergência, leia o arquivo fixado com git show <pin>:<path>; não trate o checkout mais novo como evidência fixada. Se ausente, execute o fluxo de atualização seguro e curatorial e revise a divergência da fonte antes de aceitar um novo pin.

Não reimplemente um sistema de fase, vida personalizada, minimapa, configuração, conquista ou conclusão até que as opções nativas atuais do REPENTOGON e de bibliotecas mantidas sejam comparadas. Não misture IsaacScript/TypeScript ou uma biblioteca em Lua comum a menos que o projeto já a use ou o usuário aceite.

Verificações não negociáveis

• Confirme argumentos de callback, filtro, tipo de retorno, comportamento de cancelamento/substituição e se REPENTOGON modifica o callback vanilla.
• Confirme a grafia do membro da classe e o selo de versão em um registro normalizado.
• Confirme tipo de entidade/variante/subtipo e atributos XML a partir de registros atuais ou recursos locais extraídos. Nunca adivinhe IDs numéricos ou caminhos de recurso.
• Use callbacks de cache para estatísticas do jogador e contagens de familiares. Use filtros de callback explícitos onde documentado. Evite varreduras completas de sala em callbacks por quadro/renderização, a menos que medidos e filtrados estreitamente.
• Mantenha a propriedade do jogador e o co-op local explícitos. Não assuma índice de jogador 0.
• Mantenha dados de salvamento compatíveis com JSON; carregue apenas após o início de uma partida e salve em pontos documentados do ciclo de vida. Preserve padrões ao decodificar salvamentos antigos ou parciais.
• Não copie nem modifique assets de jogo instalados. Anotações de caminho derivado são permitidas.
• Trate gráficos como assets de jogo: corresponda a cortes reais de PNG, ANM2, Lua/XML e eventos de animação. Placeholders são de desenvolvimento, nunca finais. Sem um teste visual observado no jogo, registre visual_runtime_tested: false.

Leia apenas o que a tarefa precisa

• Pergunta sobre API/callback: catálogos gerados mais knowledge/callbacks/critical-callbacks.md.
• Trabalho com XML/recurso/animação/sala: o guia correspondente em knowledge/ e esquemas fornecidos em schemas/.
• Novos sprites, fantasias, re-skins ou trabalho de animação: produção gráfica, modelo de contrato e QA visual. Execute scripts/gfx_audit.py <pasta-do-mod>; use --release para a porta de finalização/prontidão do asset final.
• Implementação: patterns/INDEX.md e a família de padrões correspondente.
• Depuração: knowledge/debugging/decision-tree.md.
• Bibliotecas: knowledge/libraries/index.md; leia a documentação/código público atual da biblioteca antes de chamá-la.

Quando referências confiáveis não contiverem uma API solicitada, diga que ela não está verificada ou não existe nas revisões indexadas. Não invente um fallback.