Crea una app TypeScript para nativo y web siguiendo las reglas del repositorio

## Ejecuta pruebas, lint y builds con los scripts del repositorio Considera el manifiesto del paquete y los scripts del repositorio como la fuente de verdad para las versiones y los comandos compatibles. Da preferencia a las API compatibles actuales y sustituye los patrones heredados u obsoletos cuando sea seguro hacerlo en el ámbito afectado. Utiliza scripts del gestor de paquetes para: - iniciar el servidor de desarrollo y cada plataforma compatible; - ejecutar pruebas unitarias, linting, comprobación de tipos y formateo; - crear compilaciones web y generar proyectos nativos. Nunca invoques directamente las herramientas subyacentes de pruebas, linting, comprobación de tipos o formateo cuando existan scripts del repositorio. Los scripts pueden aportar una configuración o una preparación que los comandos directos omiten. No ejecutes comandos de extracción o compilación de localización cuando CI se encargue de esas tareas. Añade o actualiza las cadenas traducibles del código fuente y deja que la canalización programada actualice los catálogos y las traducciones en tiempo de ejecución. Antes de cambiar el código, identifica las plataformas de destino, el script canónico de verificación y si los artefactos generados son responsabilidad del entorno local o de la automatización. ## Coloca las nuevas pantallas y componentes en la carpeta correcta Coloca en `components` los elementos de UI compartidos e independientes de la plataforma. Coloca en `screens` las rutas de página completa. Utiliza `features` para las capacidades más amplias que combinan contexto, acceso a datos, componentes y utilidades en varias pantallas. Para una pantalla compleja con componentes o estado privados, crea un directorio de pantalla y ubica allí esas dependencias. No traslades código a una carpeta compartida hasta que más de un consumidor lo necesite. Mantén los hooks de estado del servidor, las preferencias sencillas de UI, el estado de sesión y la persistencia en módulos de estado claramente definidos, o ubica el estado específico de una función junto a su consumidor. Evita los archivos grandes que mezclen responsabilidades no relacionadas. Utiliza `lib` para las utilidades reutilizables, los clientes de API, los formateadores y las constantes que no pertenezcan a una función. Evita añadir nuevos directorios de nivel superior dentro del código fuente cuando el contenido ya encaje en una responsabilidad establecida. No añadas trabajo nuevo a directorios de vistas heredados. Conserva el código heredado existente salvo que la migración forme parte de la tarea, pero coloca las pantallas, los componentes y las funciones nuevas en la estructura actual. Utiliza PascalCase para los nombres de componentes y camelCase para los archivos, directorios, variables y funciones ordinarios. Un módulo considerable puede usar una entrada `index.tsx` junto con componentes, hooks y utilidades del mismo nivel; mantén un componente pequeño en un solo archivo. Ubica la documentación opcional de una función y sus pruebas junto a los módulos más grandes. Escribe comentarios para explicar por qué existe una decisión, no lo que el código ya expresa. Utiliza bloques de documentación para las declaraciones con nombre, comentarios de bloque para explicaciones de varias líneas y comentarios de línea solo para notas breves. ## Construye la UI con el sistema de diseño y los componentes existentes Utiliza el sistema de diseño establecido antes de crear estilos sin procesar o componentes duplicados. Combina átomos independientes del tema, átomos de tema y estilos sin procesar excepcionales en este orden: 1. átomos de flex y disposición; 2. átomos de espaciado; 3. átomos de tipografía; 4. colores y superficies del tema; 5. estilos sin procesar con un ámbito estricto. Utiliza las herramientas de estilo de la plataforma para los estilos condicionales y hooks de puntos de interrupción para la disposición adaptable. Mantén las condiciones de plataforma dentro de la composición de estilos en lugar de dispersarlas por la lógica del componente. Antes de crear un control, busca en la biblioteca de componentes compartidos un botón, cuadro de diálogo, menú, campo de texto o elemento tipográfico primitivo adecuado. Sigue su API compuesta y los usos canónicos existentes. Para las declaraciones de componentes: - da preferencia a la sintaxis abreviada de fragmentos salvo que se necesite un fragmento con clave; - da preferencia a las declaraciones de funciones; - desestructura las props en la lista de parámetros; - utiliza tipos explícitos de props en línea cuando sigan siendo legibles; - asigna valores predeterminados razonables a las props opcionales; - mantén los componentes reutilizables independientes de la plataforma cuando sea posible. Utiliza campos de texto no controlados con `defaultValue` cuando la arquitectura de la plataforma presente un rendimiento deficiente con entradas controladas. Utiliza valores controlados solo cuando el comportamiento realmente los requiera. El texto generado por los usuarios puede contener emoji aunque los ejemplos no los incluyan. Activa el comportamiento seguro para emoji del sistema tipográfico en el contenido de los usuarios y omítelo solo en texto estático conocido. ## Prepara todo texto visible en pantalla para su traducción Envuelve cada cadena orientada al usuario con la macro o el componente de traducción del proyecto. Añade comentarios o contexto para quienes traducen cuando una palabra tenga varios significados, como un sustantivo y un verbo con la misma ortografía. Utiliza el punto de entrada moderno para macros compatible con el framework de traducción. Asigna un alias a su función de traducción cuando otro subsistema, como el de temas, ya utilice el mismo nombre corto de variable. Utiliza las funciones de pluralización del framework de traducción para los recuentos y su formateador de fechas para fechas y horas. El formateo del framework debe volver a ejecutarse cuando cambie el idioma activo; el formateo directo de la configuración regional a menudo no lo hace. Da preferencia a los signos de puntuación Unicode tipográficamente correctos en el texto orientado al usuario. Aplica de forma coherente las convenciones de puntuación del proyecto, incluidas las comillas y el espaciado de las rayas. No edites manualmente la salida de configuración regional generada ni ejecutes localmente tareas de extracción o compilación que pertenezcan a CI. Los cambios en el código fuente deben contener los mensajes envueltos y suficiente contexto para una traducción precisa. ## Gestiona los datos del servidor, la navegación y los archivos por plataforma Utiliza la biblioteca establecida de consultas de estado del servidor para los datos remotos y un estado basado en contexto para las preferencias sencillas de UI. Expón las preferencias mediante hooks emparejados de lectura y actualización. Crea las claves de consulta con la utilidad compartida para claves y un objeto de argumentos. La raíz de la clave debe coincidir con el nombre del hook. Utiliza nombres coherentes para los hooks de consulta, los hooks de mutación y las utilidades de mutación que solo modifican la caché. Elige los tiempos de obsolescencia entre las constantes compartidas. Para la paginación por cursor, utiliza una consulta infinita, devuelve el cursor de la respuesta como parámetro de la página siguiente y aplana las páginas solo en el límite de consumo. Cuando los datos persistentes de una consulta cambien de forma, incrementa su versión persistente para que los datos serializados obsoletos se descarten y se vuelvan a obtener. Para los fallos de mutación: - informa a los usuarios sobre los fallos de red previstos sin duplicarlos en los registros de errores; - gestiona explícitamente los errores de protocolo o API con tipo; - envía los fallos inesperados al registro estructurado con un mensaje seguro. Utiliza parámetros de ruta con tipo y la utilidad o el hook de navegación del proyecto. Mantén sincronizados la configuración de rutas, las definiciones de rutas y los tipos de ruta. Representa las implementaciones de plataforma con sufijos de nombre de archivo como `.web`, `.native`, `.ios` y `.android`. Importa la ruta del módulo base y deja que el bundler seleccione la implementación. Nunca utilices imports condicionales en tiempo de ejecución para elegir los archivos de plataforma. Da preferencia a agrupar las variantes de plataforma detrás de un único directorio de módulo. Utiliza indicadores de plataforma en tiempo de ejecución solo para el comportamiento, no para la resolución de módulos. Utiliza el alias de importación absoluta del repositorio en lugar de recorrer rutas relativas profundas. ## Evita errores de sincronía al cerrar diálogos y la memoización innecesaria Ejecuta dentro del callback de cierre del control del cuadro de diálogo toda acción que deba ocurrir después de que este se cierre. Cerrar primero y, acto seguido, navegar, abrir otra superposición, actualizar el estado afectado o invocar un callback del componente padre puede provocar una condición de carrera con la animación de cierre. La secuencia obligatoria es: 1. llamar al método de cierre; 2. proporcionar un callback a ese método; 3. realizar la navegación, la apertura de superposiciones, las actualizaciones de estado o los callbacks del componente padre dentro de él. Respeta los componentes compuestos específicos de cada plataforma. Un manejador de cuadro de diálogo o un elemento contenedor de menú puede ser exclusivo de plataformas nativas, mientras que un control de cierre o un divisor de menú puede ser exclusivo de la web. Prueba las plataformas que ejecuten cada rama. Cuando esté habilitada la memoización automática del compilador, no añadas `useMemo` ni `useCallback` de forma preventiva. Utilízalos solo ante un requisito concreto de estabilidad referencial, como una dependencia de un efecto o un contrato de una biblioteca ajena a React. No sacrifiques la legibilidad por una optimización especulativa. Mide un problema real o satisface un requisito explícito de estabilidad antes de añadir memoización manual. ## Prueba cada plataforma afectada antes de dar el trabajo por terminado Antes de terminar: 1. confirma que cada elemento interactivo tenga una etiqueta accesible y una indicación útil donde sea necesario; 2. confirma que todas las cadenas orientadas al usuario estén localizadas y que los mensajes ambiguos incluyan contexto; 3. verifica que los estilos utilicen de forma coherente los átomos del sistema de diseño, los valores de tema y las herramientas de plataforma; 4. verifica que el estado del servidor, las preferencias de UI y el estado de sesión utilicen sus mecanismos previstos; 5. confirma que no se haya duplicado un componente compartido existente; 6. confirma que las props y los parámetros de ruta tengan tipos explícitos; 7. expón identificadores de prueba estables donde los necesiten las pruebas de extremo a extremo; 8. ejecuta los scripts del repositorio para pruebas, linting, comprobación de tipos y formateo; 9. prueba todos los comportamientos nativos y web afectados. Revisa las diferencias para detectar nuevos usos de directorios heredados, imports condicionales de plataforma, ediciones directas de archivos de localización generados, regresiones entre entradas no controladas y controladas, y condiciones de carrera posteriores al cierre de cuadros de diálogo. Informa de cualquier plataforma o script canónico que no se haya podido ejecutar, incluido el requisito previo que falte. No afirmes que el trabajo multiplataforma está completo basándote en una comprobación de una sola plataforma.