unity-technologies/migrate-birp-to-urp

Clasifica la solicitud, inspecciona el estado actual del proyecto, elige la ruta de migración correcta y valida cuidadosamente el resultado de la migración de Built-in a URP.

Referencia de Ejecución Obligatoria

Para cualquier migración real o pasada de reparación, lee references/implementation-patterns.md antes de la primera llamada eval que edite configuraciones del proyecto, materiales, postprocesado, iluminación, sondas o escenas. Esto es obligatorio incluso para solicitudes cortas como "migrar este proyecto a URP" cuando la seguridad de reversión ya está confirmada.

Si ese recurso no se puede cargar, usa las reglas integradas en este SKILL.md y baja tu confianza: no declares conversión de PPv2, actualización de iluminación/sonda, ni finalización de la migración basándote solo en la intención o los registros de herramientas.

Valor Crítico por Defecto

Para solicitudes simples como "migrar este proyecto de Built-in a URP" o "pasar este proyecto a URP", inicia o reanuda el flujo de trabajo de migración seguro en lugar de saltar directamente a la conversión.

Una solicitud de actualización genérica no debe requerir que el usuario mencione cada riesgo de migración. Inspecciona y maneja dependencias comunes de Built-in como PPv2, iluminación horneada/lightmaps, sondas de reflexión, materiales de partículas/niebla/humo, niveles de calidad, postprocesado de cámara y validación de escenas representativas.

El resultado predeterminado se basa en fases:

1. Detecta si el proyecto es Built-in, parcialmente migrado, ya es URP o es HDRP.
2. Clasifica la solicitud como URP 3D estándar, URP 2D, conversión de material seleccionado, solo planificación o solución de problemas.
3. Inspecciona los riesgos de migración antes de recomendar cambios: materiales opacos, materiales de partículas/VFX, shaders personalizados, postprocesado, efectos de cámara, iluminación horneada/lightmaps/sondas de reflexión, niveles de calidad y escenas representativas.
4. Detente antes de cualquier trabajo que mute el pipeline hasta que el usuario confirme un punto de reversión como una rama, copia de seguridad, archivo o copia desechable. El trabajo que muta el pipeline incluye instalar URP, asignar un activo URP en la configuración de Gráficos/Calidad, ejecutar convertidores y editar materiales o escenas.
5. Elige la siguiente fase de migración, ejecuta esa fase, guarda/vuelve a consultar sus salidas e informa su estado.
6. Trata los shaders personalizados, GrabPass, Surface Shaders, OnRenderImage, shaders de reemplazo y shaders propiedad de paquetes como trabajo de seguimiento acotado, no trabajo automático del convertidor.
7. Valida escenas representativas, la salida de la Consola, el renderizado de la cámara, el estado de iluminación/GI horneada, materiales, la persistencia del postprocesado y las asignaciones de niveles de calidad antes de declarar el éxito total de la migración.

Fases predeterminadas:

• Fase 0: Inspeccionar y planificar. Detecta el estado del pipeline, escenas representativas, seguridad de reversión, PPv2, riesgos de material/shader, niveles de calidad, estado de iluminación/lightmap/sonda y código de renderizado personalizado.
• Fase 1: Configuración de URP y conversión de materiales compatibles. Instala/reutiliza URP, crea/asigna activos URP en Gráficos/Calidad, convierte materiales opacos y de partículas/efectos compatibles, y verifica que no queden materiales compatibles con shaders Built-in.
• Fase 2: Postprocesado y migración de cámara. Crea perfiles de Volumen URP persistentes, conecta Volúmenes de escena/postprocesado de cámara, deshabilita PPv2 heredado para validación URP y clasifica efectos PPv2 no compatibles como SSR.
• Fase 3: Iluminación, lightmaps y sondas de reflexión. Resuelve el estado obsoleto de iluminación Built-in, configura ajustes de iluminación/sonda URP, vuelve a hornear/actualizar cuando sea factible, o marca claramente la iluminación/sondas como parciales.
• Fase 4: Validación final y reporte. Guarda/recarga/vuelve a consultar el estado del proyecto, captura escenas representativas, revisa la Consola e informa elementos completos/incompletos/manuales.

Un turno puede completar múltiples fases si el proyecto es pequeño y Unity se mantiene estable, pero no fuerces todas las fases en una sola respuesta. Prefiere un límite de fase honesto sobre un resultado "completo" exagerado.

Haz preguntas de configuración solo cuando el estado del proyecto o la intención del usuario deje una decisión real sin resolver. Si el usuario dice "no modifiques archivos", quédate en modo de auditoría/planificación y no realices conversión ni ediciones de activos.

Contrato de Actualización Genérica

Cuando el usuario da una solicitud de migración genérica y permite cambios, impulsa la siguiente fase según el estado del proyecto:

1. No le pidas al usuario que enumere las funciones Built-in conocidas antes de la inspección. Descúbrelas.
2. Si existen PPv2, iluminación horneada, sondas de reflexión, materiales de partículas/niebla/humo o múltiples niveles de calidad, inclúyelos automáticamente en la migración.
3. Prefiere la finalización de fases sobre la finalización total en un solo paso. Cada fase debe guardar/vuelve a consultar sus propias salidas y terminar con Fase completa, Fase parcial o Bloqueada.
4. Si la compilación de Unity, la instalación de paquetes, la recarga de dominio o un horneado de iluminación largo interrumpen el paso, informa la interrupción como un límite de fase y reanuda desde el estado parcial guardado en el siguiente turno en lugar de empezar de nuevo.
5. No confíes en que el usuario escriba una lista de verificación detallada para obtener un comportamiento correcto. La lista de verificación detallada es para pruebas comparativas o pruebas de estrés; las solicitudes de usuario normales deben activar este contrato por fases.
6. Una solicitud de migración genérica da permiso para inspeccionar y planificar, pero no demuestra seguridad de reversión. Si no se confirma un punto de reversión, detente antes de la instalación de paquetes o la asignación de URP y pide confirmación. No dejes el proyecto en un estado parcial rosado solo para llegar a la pregunta de respaldo.
7. Si la seguridad de reversión ya está confirmada o el usuario dice que el proyecto es una copia desechable, continúa dentro de la fase actual sin preguntar de nuevo por trabajo rutinario.
8. Al final de una fase, da un aviso conciso para la siguiente fase o di qué fase debe ejecutarse a continuación. Pide confirmación antes de la siguiente fase solo cuando introduzca una operación nueva costosa o riesgosa, como un horneado de iluminación largo, eliminación/limpieza de activos heredados o una reescritura de shader personalizado.
9. Si la seguridad de reversión fue confirmada y el trabajo ordinario dentro de la fase activa permanece incompleto, no preguntes "¿quieres que continúe?". Continúa reparando esa fase hasta que su puerta pase, un límite de herramienta/recarga de dominio interrumpa la ejecución, o aparezca una decisión nueva genuinamente riesgosa.

Puerta de Éxito de Migración Genérica

Antes de decir que una migración genérica es "exitosa", "completa" o "totalmente migrada", verifica el estado guardado del proyecto, no solo los registros de herramientas:

1. Los ajustes de Gráficos y cada nivel de calidad relevante apuntan al activo URP previsto.
2. El activo URP tiene un renderizador predeterminado válido en el estado guardado, y la salida actual de la Consola no contiene errores de pipeline de renderizado no resueltos como "Falta el renderizador predeterminado". Si aparece un error de renderizador después de la asignación, vuelve a consultar la lista guardada de renderizadores/índice predeterminado, limpia la salida obsoleta de la Consola cuando sea posible, activa una nueva validación de escena/cámara y continúa la reparación en lugar de detenerte en "configuración de URP completa".
3. Los materiales Built-in compatibles, incluyendo materiales de partículas/niebla/humo, tienen shaders compatibles con URP o están listados explícitamente como casos de shader personalizados/de paquete no resueltos. Los materiales de origen texturizados/coloreados deben preservar sus mapas/colores de origen; una asignación de shader URP con _BaseMap faltante o _BaseColor todo blanco está incompleta si el _MainTex o _Color de origen tenía contenido. Los materiales de partículas, niebla, humo, vapor, decal, VFX, aditivos, transparentes y de efectos no deben forzarse ciegamente a Universal Render Pipeline/Lit; prefiere shaders de partículas/efectos URP como Universal Render Pipeline/Particles/Unlit cuando sea apropiado.
4. Si la escena de origen usaba PPv2, un perfil de Volumen URP guardado debe r