unity-technologies/migrate-birp-to-urp

Classifique a solicitação, inspecione o estado atual do projeto, escolha o caminho de migração correto e valide cuidadosamente o resultado da migração de Built-in para URP.

Referência de Execução Obrigatória

Para qualquer migração real ou passagem de reparo, leia references/implementation-patterns.md antes da primeira chamada eval que edite configurações do projeto, materiais, pós-processamento, iluminação, sondas ou cenas. Isso é obrigatório mesmo para prompts curtos como "migre este projeto para URP" quando a segurança de rollback já estiver confirmada.

Se esse recurso não puder ser carregado, use as regras incorporadas neste SKILL.md e reduza sua confiança: não declare conversão PPv2, atualização de iluminação/sonda ou conclusão de migração apenas com base em intenção ou logs de ferramentas.

Padrão Crítico

Para solicitações simples como "migre este projeto Built-in para URP" ou "mova este projeto para URP", inicie ou retome o workflow de migração segura em vez de pular diretamente para a conversão.

Um prompt de upgrade genérico não deve exigir que o usuário mencione todos os riscos de migração. Inspecione e lide com dependências Built-in comuns como PPv2, iluminação/lightmaps assados, sondas de reflexão, materiais de partícula/neblina/fumaça, níveis de Qualidade, pós-processamento de câmera e validação de cenas representativas.

O resultado padrão é baseado em fases:

1. Detecte se o projeto é Built-in, parcialmente migrado, já URP ou HDRP.
2. Classifique a solicitação como URP 3D padrão, URP 2D, conversão de material selecionado, apenas planejamento ou solução de problemas.
3. Inspecione os riscos de migração antes de recomendar alterações: materiais opacos, materiais de partícula/VFX, shaders personalizados, pós-processamento, efeitos de câmera, iluminação/lightmaps/sondas de reflexão assados, níveis de Qualidade e cenas representativas.
4. Pare antes de qualquer trabalho mutante de pipeline até que o usuário confirme um ponto de rollback como um branch, backup, arquivo ou cópia descartável. Trabalho mutante de pipeline inclui instalar URP, atribuir um asset URP nas configurações de Graphics/Quality, executar conversores e editar materiais ou cenas.
5. Escolha a próxima fase de migração, execute essa fase, salve/re-consulte suas saídas e relate o status da fase.
6. Trate shaders personalizados, GrabPass, Surface Shaders, OnRenderImage, shaders de substituição e shaders de pacotes como trabalho de acompanhamento com escopo definido, não trabalho automático de conversor.
7. Valide cenas representativas, saída do Console, renderização de câmera, estado de iluminação/GI assado, materiais, persistência de pós-processamento e atribuições de níveis de Qualidade antes de declarar sucesso total da migração.

Fases padrão:

• Fase 0: Inspecionar e planejar. Detecte estado do pipeline, cenas representativas, segurança de rollback, PPv2, riscos de material/shader, níveis de Qualidade, estado de iluminação/lightmap/sonda e código de renderização personalizado.
• Fase 1: Configuração URP e conversão de material suportada. Instale/reutilize URP, crie/atribua assets URP em Graphics/Quality, converta materiais opacos e de partícula/efeito suportados e verifique se nenhum material suportado permanece em shaders Built-in.
• Fase 2: Pós-processamento e migração de câmera. Crie perfis de Volume URP persistentes, conecte Volumes de cena/pós-processamento de câmera, desabilite PPv2 legado para validação URP e classifique efeitos PPv2 não suportados como SSR.
• Fase 3: Iluminação, lightmaps e sondas de reflexão. Resolva estado de iluminação Built-in obsoleto, configure iluminação/configurações de sonda URP, re-assa/atualize quando viável ou marque claramente iluminação/sondas como parciais.
• Fase 4: Validação final e relatório. Salve/recarregue/re-consulte o estado do projeto, capture cenas representativas, verifique o Console e relate itens completos/incompletos/manuais.

Uma rodada pode completar múltiplas fases se o projeto for pequeno e o Unity permanecer estável, mas não force todas as fases em uma resposta. Prefira um limite de fase honesto em vez de um resultado "completo" superestimado.

Faça perguntas de configuração apenas quando o estado do projeto ou a intenção do usuário deixar uma decisão real não resolvida. Se o usuário disser "não modifique arquivos", permaneça no modo auditoria/planejamento e não realize conversão ou edições de assets.

Contrato de Upgrade Genérico

Quando o usuário dá uma solicitação de migração genérica e permite alterações, conduza a próxima fase a partir do estado do projeto:

1. Não peça ao usuário para enumerar recursos Built-in conhecidos antes da inspeção. Descubra-os.
2. Se PPv2, iluminação assada, sondas de reflexão, materiais de partícula/neblina/fumaça ou múltiplos níveis de Qualidade existirem, inclua-os na migração automaticamente.
3. Prefira conclusão de fase em vez de conclusão tudo-em-um. Cada fase deve salvar/re-consultar suas próprias saídas e terminar com Fase completa, Fase parcial ou Bloqueada.
4. Se compilação Unity, instalação de pacote, recarga de domínio ou uma longa assadura de luz interromper a passagem, relate a interrupção como um limite de fase e retome do estado parcial salvo na próxima rodada, em vez de recomeçar.
5. Não confie no usuário escrevendo um prompt de checklist detalhado para obter comportamento correto. O checklist detalhado é para benchmark ou teste de estresse; prompts normais de usuário ainda devem acionar este contrato faseado.
6. Uma solicitação de migração genérica dá permissão para inspecionar e planejar, mas não prova segurança de rollback. Se nenhum ponto de rollback for confirmado, pare antes de instalação de pacote ou atribuição URP e peça confirmação. Não deixe o projeto em um estado parcial magenta apenas para chegar à pergunta de backup.
7. Se a segurança de rollback já estiver confirmada ou o usuário disser que o projeto é uma cópia descartável, continue dentro da fase atual sem perguntar novamente para trabalho rotineiro.
8. Ao final de uma fase, dê um prompt conciso para a próxima fase ou diga qual fase deve ser executada em seguida. Peça confirmação antes da próxima fase apenas quando ela introduzir uma nova operação custosa ou arriscada, como uma longa assadura de luz, exclusão/limpeza de assets legados ou uma reescrita de shader personalizado.
9. Se a segurança de rollback foi confirmada e o trabalho comum dentro da fase ativa permanecer incompleto, não pergunte "gostaria que eu continuasse?" Continue reparando essa fase até que sua porta passe, uma ferramenta/recarga de domínio interrompa a execução ou uma decisão genuinamente nova e arriscada apareça.

Portão de Sucesso de Migração Genérica

Antes de dizer que uma migração genérica é "bem-sucedida", "completa" ou "totalmente migrada", verifique o estado salvo do projeto, não apenas logs de ferramentas:

1. As configurações de Graphics e cada nível de Qualidade relevante apontam para o asset URP pretendido.
2. O asset URP tem um renderizador padrão válido no estado salvo, e a saída atual do Console não contém erros de render pipeline não resolvidos como "Default Renderer is missing". Se um erro de renderizador aparecer após a atribuição, re-consulte a lista de renderizadores salvos/índice padrão, limpe saída obsoleta do Console quando possível, dispare uma validação de cena/câmera fresca e continue o reparo em vez de parar em "configuração URP completa".
3. Materiais Built-in suportados, incluindo materiais de partícula/neblina/fumaça, têm shaders compatíveis com URP ou são explicitamente listados como casos de shader personalizados/de pacote não resolvidos. Materiais fonte texturizados/coloridos devem preservar seus mapas/cores de origem; uma atribuição de shader URP com _BaseMap ausente ou _BaseColor todo branco é incompleta se a _MainTex ou _Color de origem tinha conteúdo. Materiais de partícula, neblina, fumaça, vapor, decalque, VFX, aditivo e efeito transparente não devem ser forçados cegamente para Universal Render Pipeline/Lit; prefira shaders de partícula/efeito URP como Universal Render Pipeline/Particles/Unlit quando apropriado.
4. Se a cena de origem usava PPv2, um perfil de Volume URP salvo deve existir e conter efeitos compatíveis que reflitam a intenção visual original. Overrides de Volume nivelados a câmera e a cena devem ser verificados. Se um efeito PPv2 como Depth of Field não tiver um equivalente URP, isso deve ser relatado como manual/ausente, não automaticamente satisfeito.
5. Iluminação, lightmaps e sondas de reflexão não requerem nova assadura para conclusão de fase, mas o estado deve ser verificado e marcado como parcial se eles permaneceram Built-in. Silenciar sondas de Built-in para URP sem dizer "iluminação/sondas parcial" é um relatório incompleto.