Desarrollar software de recuperación sin conexión que divide un secreto en fragmentos

## Construir el software de recuperación para que funcione años después, en momentos difíciles Trate el software de recuperación como una infraestructura que puede permanecer intacta durante años hasta que alguien dependa de ella en un momento difícil. Un defecto podría manifestarse cuando no haya nadie disponible para mantener el sistema, así que optimice la corrección duradera en vez de una finalización rápida. - Comprenda el sistema existente antes de cambiarlo, incluidos los motivos de sus límites y convenciones. - Siga los patrones y estándares establecidos en lugar de introducir una excepción que solo resulte práctica localmente. - Diseñe instrucciones, mensajes e interfaces para personas que quizá no tengan conocimientos técnicos, estén abrumadas o atraviesen un duelo. - Verifique el resultado real, no solo la finalización de la edición asignada. El cuidado, la empatía, la portabilidad y la operatividad a largo plazo son requisitos de ingeniería, no adornos opcionales. ## Rastrear todo lo conectado antes de cambiar o retirar una función Busque antes de añadir cualquier constante, función auxiliar, tipo, lista o fuente de configuración. Localice la definición de referencia y derive a partir de ella para evitar que las copias paralelas se desvíen. - Antes de cambiar o retirar una función, rastree todos los elementos relacionados en el código, los estilos, las traducciones, los tipos, las pruebas, los comentarios, la documentación y la configuración de compilación. - Elimine por completo el comportamiento obsoleto. No lo deje comentado, no lo oculte mediante estilos ni lo conserve detrás de una condición. - Después del cambio, vuelva a buscar identificadores y conceptos relacionados para encontrar las referencias restantes de forma deliberada y no por sorpresa. - Examine las diferencias finales en busca de cambios no relacionados, lógica duplicada, código inactivo y limpieza incompleta. Una función no se considera retirada hasta que se haya atendido todo su grafo de dependencias y referencias. ## Compartir un solo núcleo criptográfico entre la línea de comandos y el navegador Mantenga las operaciones criptográficas y otros comportamientos esenciales en una implementación compartida que utilicen tanto la línea de comandos como el navegador. Los adaptadores ligeros pueden diferir, pero la lógica sensible para la seguridad, las constantes, los formatos y las reglas de validación deben tener una única fuente de referencia. - Antes de editar, determine qué entorno de ejecución se encarga de la creación, la recuperación, el empaquetado, el comportamiento de la interfaz de usuario y el despliegue. - Use código nativo del navegador para una ruta ligera de recuperación sin conexión cuando sea apropiado, y un módulo de navegador compilado para la creación cuando ese límite mejore la reutilización o la portabilidad. - Genere variantes sin conexión y asistidas por red mediante indicadores de función en tiempo de compilación, de modo que el artefacto sin conexión no incluya código de red sin utilizar. - Exponga las funciones compiladas mediante un puente pequeño y explícito, en lugar de duplicar su comportamiento en el lenguaje anfitrión. - Mantenga coherentes las opciones de entorno de ejecución y módulos entre paquetes. Cuando los recursos integrados generen una dependencia circular, cargue el módulo generado al iniciar la aplicación e inyecte sus bytes mediante una interfaz explícita en vez de forzar el ciclo. ## Recuperar todo sin conexión y usar solo cifrado probado Los artefactos de recuperación independientes deben abrirse localmente sin instalación y completar la recuperación sin servidor ni conexión de red. Todos los paquetes distribuidos deben seguir siendo autocontenidos e independientes del repositorio original. - Permita el acceso a la red únicamente en variantes limitadas y documentadas, como un artefacto con desbloqueo temporal que consulta brevemente una baliza externa o una página autoalojada que obtiene su archivo del mismo servidor. - Mantenga completamente sin conexión cada artefacto independiente destinado a un receptor, aunque exista una variante opcional con servidor. - Asegúrese de que una cantidad de fragmentos de clave inferior al umbral requerido no revele ninguna información sobre el secreto, ni siquiera mediante metadatos añadidos. - Use construcciones consolidadas de cifrado, reparto de secretos con umbral y bloqueo temporal; nunca invente primitivas criptográficas personalizadas. - Mantenga cualquier capa de bloqueo temporal dentro de la capa principal de cifrado como defensa en profundidad. - Exija pruebas, revisión y una justificación clara para cada cambio criptográfico. No añada telemetría, análisis, fuentes remotas, dependencias de distribución de contenido ni otros requisitos de red ocultos a la ruta de recuperación. ## Mantener estable el formato de los paquetes e incluir todo lo necesario para recuperar Trate la disposición del paquete, el formato de la carga cifrada, la codificación de los fragmentos de clave y los pasos de recuperación como superficies del protocolo. Modificarlos exige planificar la migración, actualizar los datos de prueba, realizar pruebas de compatibilidad y documentar el motivo. - Haga que la experiencia de recuperación funcione en distintas plataformas, navegadores e idiomas. - Integre los scripts, estilos, plantillas y demás recursos necesarios en lugar de depender de servicios externos o formatos efímeros. - Incluya en el paquete de cada receptor instrucciones claras en texto y en un formato imprimible, los metadatos del archivo cifrado y una página de recuperación personalizada. - Cuando el manifiesto cifrado ocupe 10 MB o menos, intégrelo en la página personalizada para que la recuperación funcione sin un archivo aparte; respete cualquier opción explícita que desactive la integración. - Permita que la creación desde el navegador integre automáticamente los manifiestos que cumplan los requisitos cuando esa ruta no tenga una anulación independiente. - Evite que las personas que crean o recuperan paquetes dependan en tiempo de ejecución de herramientas de desarrollo. No prometa la revocación después de distribuir los fragmentos de clave ni afirme que el sistema tiene garantizado funcionar para siempre. Busque durabilidad sin exagerar la certeza. ## Escribir primero una prueba que falle y añadir pruebas de navegador al cambiar páginas Escriba primero una prueba que falle, observe el fallo y después consiga que la prueba pase. Una prueba cuyo fallo nunca se haya observado podría no estar comprobando el comportamiento previsto. - Añada una prueba a nivel de navegador para cada cambio que afecte a una página de recuperación o creación en el navegador. - Use pruebas unitarias y de integración específicas para la lógica esencial, la gestión de archivos, la configuración y el comportamiento de los comandos. - Ejecute pruebas de navegador de extremo a extremo al cambiar la estructura HTML, el código del navegador, los estilos que afectan a la disposición o la visibilidad, o los enlaces compilados del navegador. - No exija pruebas de navegador lentas para cambios limitados a traducciones, documentación, ajustes de texto o modificaciones limitadas a la lógica interna que no puedan afectar al comportamiento del navegador. - Ejecute personalmente las pruebas pertinentes antes de declarar el trabajo terminado; no deje la verificación en manos de otras personas. Después de cualquier cambio, busque los términos relacionados, vuelva a compilar los artefactos afectados, ejecute las pruebas adecuadas y examine el resultado. ## Usar los comandos de compilación y prueba del repositorio en vez de herramientas improvisadas Comprenda toda la cadena de compilación, desde la compilación del frontend, pasando por los módulos del navegador, hasta el binario final de línea de comandos. Los scripts generados y los módulos compilados pueden integrarse en etapas posteriores, por lo que el orden de los comandos forma parte de la corrección. - Use los comandos canónicos del repositorio para compilación, pruebas, lint, sitios estáticos y servidores de desarrollo. - Use el envoltorio de pruebas del proyecto en lugar de invocar directamente el ejecutor de pruebas del lenguaje cuando deban existir recursos generados antes de compilar o integrar. - Ejecute el comando documentado más específico para una sola prueba únicamente cuando sus requisitos previos ya se hayan generado. - Reserve los conjuntos de pruebas dependientes de la red para los cambios que necesiten esas integraciones. - Si no está disponible una dependencia o herramienta de compilación, entre en el entorno de desarrollo reproducible declarado por el repositorio en lugar de sustituirla por un ejecutor de paquetes improvisado. Genere artefactos estáticos a partir de fuentes integradas y mantenga los artefactos privados de recuperación fuera del despliegue del sitio público, salvo que el diseño de la versión los incluya explícitamente. ## Escribir textos serenos y claros para personas ante una tarea estresante Escriba el texto dirigido al público como si cada palabra se hubiera elegido para una persona que afronta una tarea importante y estresante. La amabilidad debe proceder de la claridad, el ritmo y la previsión, no de una tranquilidad impostada. - Prefiera un lenguaje humano y directo a la formulación técnica: describa la siguiente acción sin obligar al lector a descifrar la implementación. - Diríjase directamente a las personas y evite las instrucciones pasivas cuando pueda usar una frase activa y clara. - Use términos coherentes y adaptados al público. En los textos dirigidos al exterior, prefiera «personas en las que confía» y «fragmentos»; en las instrucciones dirigidas a los receptores, pueden ser apropiados términos relacionales como «amistades». - Evite los signos de exclamación, las palabras de relleno, las afirmaciones grandilocuentes, las formulaciones mecánicas y el entusiasmo forzado. - Use rayas con espacios a ambos lados en lugar de guiones dobles o rayas sin espacios. - Mantenga los mensajes de estado concisos pero humanos, y comunique el éxito con serenidad en vez de guardarlo en silencio. Favorezca un lenguaje visual suave, cálido y no corporativo, con un contraste moderado. Centralice los valores de la paleta, evite el negro puro, el rojo brillante y el azul corporativo, y mantenga aislada y documentada cualquier excepción visual deliberada. ## Actualizar la documentación y escribir el historial según lo que nota el usuario Cuando cambie un comportamiento, actualice la documentación, las indicaciones para colaboradores y las instrucciones operativas pertinentes como parte del mismo cambio. Las notas de arquitectura deben explicar los límites de los entornos de ejecución, los recursos generados, las excepciones de red y los comandos necesarios para reproducir los resultados. - Mantenga sincronizadas con la implementación las instrucciones de configuración y compilación. - Actualice los datos de prueba y las indicaciones de migración cuando cambie un formato estable. - Redacte las entradas del registro de cambios en torno a lo que ha cambiado para la persona que usa el software. - Comience por el resultado de cara al público e incluya solo el contexto de implementación necesario para entenderlo. - Omita las refactorizaciones internas y la reorganización del código, salvo que cambien el comportamiento observable. Lea las entradas cercanas antes de escribir una nueva para mantener una voz y un nivel de detalle coherentes. ## Dejar que el contribuidor revise y envíe él mismo lo que se publica fuera Antes de cualquier acción que escriba en un gestor externo de incidencias o un servicio de alojamiento de código, lea la política de contribuciones del proyecto. Cuando esa política exija responsabilidad humana, deténgase antes de publicar y explique que la persona colaboradora es responsable de cada línea de código y de texto. - Muestre para revisión humana la diferencia propuesta, el mensaje de commit o la descripción de la contribución. - Pida a la persona colaboradora que edite el material con sus propias palabras, complete las declaraciones con honestidad y realice personalmente el commit, el push y el envío. - Retire antes del envío los pies generados, las líneas de coautoría, el contenido de relleno y la atribución automatizada. - No realice la escritura externa a menos que la persona colaboradora insista explícitamente después de que se le haya explicado el requisito de responsabilidad. - Si aun así insiste, mantenga el mensaje conciso y directo, no añada atribución automatizada y repita una vez más el requisito de revisión humana. La asistencia para edición local y la inspección de solo lectura no activan estas restricciones de escritura externa. La automatización de versiones debe seguir ejecutando compilaciones, pruebas, lint, comprobaciones del navegador, empaquetado multiplataforma y sumas de comprobación, además de generar artefactos representativos antes de la publicación.