Añade funciones a una app de escritorio por capas y prueba cada compilación

## Decide qué hace el núcleo, el host de escritorio y la interfaz Define las plataformas que se distribuirán, los clientes compatibles, la topología de procesos y los límites de confianza antes de modificar el código. - Mantén las reglas de negocio, la persistencia, la ejecución y el comportamiento del dominio en un núcleo autorizado. - Haz que el host de escritorio sea responsable del ciclo de vida, las capacidades nativas, el puente seguro y el empaquetado. - Haz que la interfaz orientada a la web sea responsable de la presentación, la navegación y la orquestación; no dupliques las reglas del núcleo en el renderizador. - Dirige las llamadas de la interfaz al núcleo a través de una única abstracción de transporte autenticada, en lugar de usar accesos directos improvisados. - Trata los clientes experimentales como superficies de compatibilidad independientes con estados explícitos de transporte, cifrado y publicación. - Mantén un mapa de arquitectura que identifique cada capa, el estado que posee, sus interfaces públicas y las responsabilidades que tiene prohibidas. ## Clasifica los comandos por riesgo y limita las herramientas a la carpeta del usuario Centraliza la configuración y aplica una única política de denegación predeterminada a todas las herramientas que ejecutan acciones. - Lee los valores del entorno mediante módulos de configuración tipados; el código de las funciones no debe acceder directamente a variables del entorno de proceso ni de compilación. - Modela la autonomía como niveles explícitos combinados con límites del espacio de trabajo, raíces de confianza y permisos de instalación. - Clasifica los comandos como lectura, escritura, red, instalación o destrucción; trata los comandos no reconocidos como operaciones de escritura. - Resuelve cada clase como permitida, sujeta a confirmación o bloqueada según el nivel activo. Bloquea siempre las ubicaciones del sistema y de credenciales. - Separa la raíz de acción del usuario del estado interno de la aplicación. Las herramientas solo pueden actuar dentro de la raíz de acción y nunca deben escribir directamente en el estado interno. - Mantén activadas de forma predeterminada las puertas de aprobación para las mutaciones interactivas, establece una caducidad para las solicitudes sin respuesta y haz que la caducidad deniegue la acción. - Combina la validación de rutas de la aplicación con un entorno aislado del sistema operativo o del contenedor; el aislamiento es una defensa en profundidad, no un sustituto de las comprobaciones de políticas. ## Da a cada dominio su propio módulo dentro del núcleo Asigna a cada dominio un módulo propio con una propiedad clara y archivos pequeños y componibles. ### Usa una estructura de módulo canónica - Mantén la fachada del módulo centrada en las exportaciones y libre de lógica de negocio. - Cuando existan esas responsabilidades, coloca en archivos separados los tipos de dominio serializables, la persistencia, las operaciones, los esquemas de controladores, las herramientas de agente, los suscriptores de eventos y las pruebas. - Coloca las herramientas propias de un dominio junto a él y reserva la infraestructura compartida de herramientas para comportamientos realmente transversales. - Limita los módulos de transporte a la autenticación, el despacho, el registro, la observabilidad y los aspectos del protocolo. Expón los controladores mediante un registro de pares de esquema y manejador. El comportamiento nuevo debe añadir un controlador de dominio y registrarlo en un único punto de composición, en lugar de aumentar las ramas por nombre de comando en todo el código de transporte. ## Mantén los ajustes de encendido y apagado en ejecución separados de las funciones de compilación Modela dos ejes independientes: - Un conjunto de servicios selecciona los servicios en segundo plano y los transportes que se ejecutan. - Un conjunto de dominios selecciona las familias de dominio disponibles en tiempo de ejecución. - Las funciones de compilación excluyen código y dependencias para las variantes del producto. El filtrado en tiempo de ejecución debe retirar de la superficie activa los controladores, las herramientas, los almacenes y los suscriptores de un dominio desactivado. Las puertas de compilación deben combinarse con ese comportamiento sin cambiar la compilación predeterminada. Mantén el punto de registro como fuente autorizada para que los esquemas, el despacho, las herramientas y los servicios de inicio no se desvíen entre sí. ## Elige cómo desactivar funciones opcionales según sus dependencias reales Elige la puerta más pequeña que conserve el comportamiento siempre activo. 1. Usa una puerta de hoja cuando todas las referencias externas sean puntos de registro; las superficies de capacidad desactivadas deben estar ausentes, no registradas como stubs que fallan. 2. Usa una fachada con stubs de comportamiento solo cuando los llamadores que siempre se compilan necesiten símbolos invocables. 3. Separa los tipos compartidos sin dependencias en módulos que siempre se compilen y sustituye únicamente el comportamiento por stubs. Nunca dupliques definiciones de tipos entre compilaciones activadas y desactivadas. 4. Divide un directorio cuando algunas utilidades sirvan a dominios siempre activos; controla los enlaces de dependencia reales, no los nombres de carpetas. 5. Conserva las funciones auxiliares esenciales aunque se encuentren bajo un dominio opcional. No sustituyas una implementación necesaria por un stub con apariencia de éxito. Cuando un comando siga visible aunque su función se haya excluido de la compilación, devuelve un error explícito de compilación desactivada en lugar de un engañoso error de comando desconocido. Para los datos inertes en la compilación que todavía nombren componentes desactivados, haz que la resolución tolere identificadores ausentes y prueba ese contrato. Nunca afirmes que una puerta de función elimina dependencias basándote únicamente en una compilación correcta. Demuestra cada eliminación declarada mediante una consulta inversa del árbol de dependencias en la configuración desactivada. ## Prueba las compilaciones con las funciones opcionales activadas y desactivadas Trata las pruebas como parte de la arquitectura y cubre el comportamiento, la integración y el empaquetado. - Coloca las pruebas unitarias específicas junto al código correspondiente y da prioridad al comportamiento observable sobre los detalles de implementación. - Usa un servicio simulado compartido para pruebas de integración deterministas; prohíbe el acceso real a la red y las esperas dependientes del tiempo en los conjuntos de pruebas unitarias. - Define escenarios de extremo a extremo antes de implementar, incluidos los recorridos correctos, los fallos, las puertas de autorización y la recuperación. - Prueba las funciones opcionales en ambos sentidos: demuestra el registro cuando están activadas y su ausencia cuando están desactivadas. - Ejecuta explícitamente el conjunto de pruebas de la compilación desactivada. Una vía de comprobación rápida que solo compila no compila el código de prueba y no puede demostrar que las pruebas sujetas a puertas sigan siendo válidas. - Impón un umbral de cobertura de líneas modificadas y recurre al conjunto completo cuando cambien la configuración compartida o los contratos fundamentales. - Compila una sola vez los artefactos de plataforma costosos y distribuye las pruebas desde ese artefacto cuando el sistema de compilación lo permita. ## Añade registros de diagnóstico que no guarden secretos ni datos personales Los flujos nuevos y modificados requieren diagnósticos en la entrada, la salida, las ramas, las llamadas externas, los reintentos, los tiempos de espera, las transiciones de estado y los errores. - Usa prefijos de dominio estables y fáciles de buscar con grep, además de campos de correlación como identificadores de solicitud y nombres de métodos. - Mantén concisos los registros normales, pero proporciona en los niveles debug y trace suficiente información para investigaciones específicas. - Nunca registres en el sistema de analítica secretos, credenciales sin procesar, datos personales completos, contenido escrito por usuarios, identificadores de entidades, nombres de archivo ni mensajes de error sin procesar. - Dirige la analítica a través de una única API de funciones que tenga en cuenta el consentimiento y usa nombres de eventos estables y sin contenido. - Considera incompleta la implementación si faltan diagnósticos cuando el cambio introduce una ruta de ejecución nueva. ## Traduce todos los textos de la interfaz y no edites a mano los documentos generados Usa estados, transportes y localización centralizados en lugar de atajos locales. - Da prioridad a la capa de estado de aplicación designada frente al almacenamiento disperso del navegador. - Usa el cliente compartido del núcleo para todas las llamadas al núcleo y mantén alineado el comportamiento de los transportes paralelos. - Protege las API exclusivas del entorno nativo mediante el detector de entorno de ejecución y el límite de errores compatibles. - Dirige todas las cadenas visibles a través de la localización, añade traducciones reales para cada configuración regional compatible y conserva exactamente los marcadores de interpolación. - Ejecuta comprobaciones de sintaxis de localización, filtraciones de inglés y cobertura antes de terminar. - Nunca edites manualmente los bloques de documentación generados. Actualiza su marcador de origen, vuelve a generarlos y deja que las comprobaciones de divergencia rechacen los resultados obsoletos. - Evita añadir inyección de scripts a vistas de terceros integradas; implementa el comportamiento nuevo mediante manejadores nativos, herramientas de protocolo o enlaces IPC controlados. ## Crea cada función del núcleo a la interfaz, probando cada capa antes de seguir Sigue un flujo vertical fijo: 1. Especifica el comportamiento a partir de los contratos de dominio, las convenciones de nombres, la política de seguridad y los escenarios de extremo a extremo existentes. 2. Implementa la lógica de dominio autorizada con pruebas unitarias. 3. Demuestra el límite del controlador o RPC mediante una prueba de integración. 4. Presenta el comportamiento en la interfaz mediante el cliente compartido y conserva las reglas en el núcleo. 5. Añade pruebas unitarias de interfaz y cobertura de extremo a extremo de la plataforma. 6. Actualiza los metadatos de capacidades orientados al usuario y la documentación de arquitectura cuando se añada, retire o cambie el nombre de una función. No avances a la capa siguiente mientras la actual no tenga pruebas. Mantén los módulos pequeños y con un único propósito, y actualiza la documentación junto con el comportamiento que rige. ## No te saltes las comprobaciones obligatorias y muestra sus resultados antes de terminar Realiza los cambios en una rama específica, dirige el trabajo a la rama de integración designada por el repositorio y mantén las publicaciones de producción vinculadas a la fuente de publicación declarada. - Usa desde la raíz del repositorio el gestor de paquetes canónico, la cadena de herramientas fijada, el formateador, el linter, el comprobador de tipos y los ejecutores de pruebas. - Mantén sincronizados los ajustes equivalentes de perfiles de compilación entre los componentes nativos que se compilan por separado. - Nunca omitas los ganchos ni las comprobaciones obligatorias para ocultar fallos. Si un gancho genera archivos, revisa e incluye los resultados y vuelve a ejecutarlo. - Corrige los fallos causados por el cambio; documenta los bloqueos preexistentes no relacionados en vez de debilitar silenciosamente las protecciones. - Revisa la diferencia final para comprobar la coherencia de la implementación, las pruebas, los esquemas, los artefactos generados, la localización y la documentación. - No declares el trabajo terminado sin resultados directos de las comprobaciones pertinentes para cada capa modificada y cada configuración de compilación compatible.