Desenvolver software de recuperação sem conexão que divide um segredo em fragmentos

## Construir o software de recuperação para funcionar anos depois, em momentos difíceis Trate o software de recuperação como uma infraestrutura que pode permanecer intocada por anos até que alguém dependa dela em um momento difícil. Um defeito pode aparecer quando não houver ninguém disponível para fazer a manutenção, por isso priorize a correção duradoura em vez da conclusão rápida. - Entenda o sistema existente antes de alterá-lo, inclusive por que seus limites e convenções existem. - Siga os padrões e normas estabelecidos em vez de introduzir uma exceção conveniente apenas no contexto local. - Crie instruções, mensagens e interfaces para pessoas que talvez não tenham conhecimentos técnicos, estejam sobrecarregadas ou enfrentem o luto. - Verifique o resultado real, não apenas a conclusão da edição atribuída. Cuidado, empatia, portabilidade e capacidade de operação no longo prazo são requisitos de engenharia, não acabamentos opcionais. ## Rastrear tudo o que está ligado antes de mudar ou retirar uma função Pesquise antes de adicionar qualquer constante, função auxiliar, tipo, lista ou fonte de configuração. Localize a definição de referência e faça as derivações a partir dela para impedir que cópias paralelas se afastem entre si. - Antes de alterar ou remover uma funcionalidade, rastreie todos os elementos relacionados no código, nos estilos, nas traduções, nos tipos, nos testes, nos comentários, na documentação e na configuração de compilação. - Remova completamente o comportamento obsoleto. Não o transforme em comentário, não o esconda com estilos nem o deixe atrás de uma condição. - Após a mudança, pesquise novamente os identificadores e conceitos relacionados para encontrar deliberadamente as referências restantes, em vez de ser surpreendido por elas. - Examine a diferença final em busca de alterações não relacionadas, lógica duplicada, código inativo e limpeza incompleta. Uma funcionalidade só pode ser considerada removida depois que todo o seu grafo de dependências e referências tiver sido tratado. ## Compartilhar um só núcleo criptográfico entre a linha de comando e o navegador Mantenha as operações criptográficas e outros comportamentos essenciais em uma implementação compartilhada, usada tanto pelo caminho da linha de comando quanto pelo caminho do navegador. Adaptadores leves podem ser diferentes, mas a lógica sensível à segurança, as constantes, os formatos e as regras de validação devem ter uma única fonte de referência. - Antes de editar, determine qual ambiente de execução é responsável pela criação, recuperação, montagem de pacotes, comportamento da interface do usuário e implantação. - Use código nativo do navegador em um caminho leve de recuperação sem conexão quando apropriado, e um módulo de navegador compilado para criação quando esse limite melhorar a reutilização ou a portabilidade. - Produza variantes sem conexão e assistidas pela rede usando sinalizadores de funcionalidade durante a compilação, para que o artefato sem conexão não contenha código de rede desnecessário. - Exponha funções compiladas por meio de uma ponte pequena e explícita, em vez de duplicar o comportamento delas na linguagem hospedeira. - Mantenha coerentes as escolhas de ambiente de execução e de módulos entre os pacotes. Quando recursos incorporados criarem uma dependência circular, carregue o módulo gerado durante a inicialização do aplicativo e injete seus bytes por meio de uma interface explícita, em vez de forçar o ciclo. ## Fazer toda a recuperação sem conexão e usar só criptografia comprovada Artefatos independentes de recuperação devem abrir localmente sem instalação e concluir a recuperação sem servidor nem conexão de rede. Todo pacote distribuído deve continuar autocontido e independente do repositório original. - Permita acesso à rede apenas em variantes limitadas e documentadas, como um artefato com desbloqueio programado que verifica brevemente um sinal externo ou uma página auto-hospedada que obtém o arquivo do mesmo servidor. - Mantenha cada artefato independente destinado a um destinatário totalmente sem conexão, mesmo quando existir uma variante opcional com servidor. - Garanta que uma quantidade de fragmentos de chave inferior ao limiar exigido não revele nenhuma informação sobre o segredo, inclusive por meio de metadados adicionados. - Use construções consolidadas de criptografia, compartilhamento de segredo com limiar e bloqueio temporal; nunca invente primitivas criptográficas próprias. - Mantenha qualquer camada de bloqueio temporal dentro da camada principal de criptografia como defesa em profundidade. - Exija testes, revisão e uma justificativa clara para toda mudança criptográfica. Não adicione telemetria, análises, fontes remotas, dependências de distribuição de conteúdo nem outros requisitos de rede ocultos ao caminho de recuperação. ## Manter estável o formato dos pacotes e incluir tudo o que a recuperação precisa Trate a estrutura do pacote, o formato da carga criptografada, a codificação dos fragmentos de chave e as etapas de recuperação como partes do protocolo. Alterá-los exige planejamento da migração, atualização dos dados de teste, testes de compatibilidade e um motivo documentado. - Faça a experiência de recuperação funcionar em diferentes plataformas, navegadores e idiomas. - Incorpore scripts, estilos, modelos e outros recursos necessários, em vez de depender de serviços externos ou formatos efêmeros. - Inclua em cada pacote do destinatário instruções claras em texto e em formato imprimível, os metadados do arquivo criptografado e uma página de recuperação personalizada. - Quando o manifesto criptografado tiver 10 MB ou menos, incorpore-o à página personalizada para que a recuperação funcione sem um arquivo separado; respeite uma opção explícita que desative essa incorporação. - Permita que a criação pelo navegador incorpore automaticamente os manifestos qualificados quando não houver uma configuração separada que substitua esse comportamento. - Evite dependências de ferramentas de desenvolvimento em tempo de execução para as pessoas que criam ou recuperam pacotes. Não prometa revogação depois que os fragmentos de chave forem distribuídos nem afirme que o sistema tem garantia de funcionar para sempre. Busque durabilidade sem exagerar a certeza. ## Escrever primeiro um teste que falhe e adicionar testes de navegador ao mudar páginas Primeiro escreva um teste que falhe, observe a falha e depois faça o teste passar. Um teste cuja falha nunca foi observada talvez não esteja verificando o comportamento pretendido. - Adicione um teste no nível do navegador para toda mudança que afete uma página de recuperação ou criação no navegador. - Use testes unitários e de integração focados na lógica principal, no tratamento de arquivos, na configuração e no comportamento dos comandos. - Execute testes de navegador de ponta a ponta ao alterar a estrutura HTML, o código do navegador, estilos que afetem o layout ou a visibilidade, ou integrações compiladas do navegador. - Não exija testes de navegador lentos para alterações limitadas a traduções, documentação, ajustes de texto ou mudanças somente na lógica interna que não possam afetar o comportamento do navegador. - Execute pessoalmente os testes relevantes antes de informar a conclusão; não deixe a verificação para outra pessoa. Depois de qualquer mudança, pesquise os termos relacionados, reconstrua os artefatos afetados, execute os testes adequados e examine o resultado. ## Usar os comandos de compilação e teste do repositório em vez de ferramentas improvisadas Entenda toda a cadeia de compilação, desde a compilação do código da interface, passando pelos módulos do navegador, até o binário final de linha de comando. Scripts gerados e módulos compilados podem ser incorporados a etapas posteriores, portanto a ordem dos comandos faz parte da correção. - Use os comandos canônicos do repositório para compilação, testes, lint, sites estáticos e servidores de desenvolvimento. - Use o wrapper de testes do projeto em vez de invocar diretamente o executor de testes da linguagem quando recursos gerados precisarem existir antes da compilação ou incorporação. - Execute o comando documentado mais específico para um único teste somente quando os respectivos pré-requisitos já tiverem sido gerados. - Reserve os conjuntos de testes dependentes de rede para mudanças que exijam essas integrações. - Se uma dependência ou ferramenta de compilação não estiver disponível, entre no ambiente de desenvolvimento reproduzível declarado pelo repositório em vez de substituí-la por um executor de pacotes improvisado. Crie artefatos estáticos a partir de fontes incorporadas e mantenha os artefatos privados de recuperação fora da implantação do site público, a menos que o projeto da versão os inclua explicitamente. ## Escrever textos calmos e claros para pessoas diante de uma tarefa estressante Escreva textos voltados ao público como se cada palavra tivesse sido escolhida para uma pessoa diante de uma tarefa importante e estressante. A gentileza deve vir da clareza, do ritmo e da antecipação, não de uma tranquilização encenada. - Prefira uma linguagem humana e direta a formulações técnicas: descreva a próxima ação sem obrigar quem lê a decifrar a implementação. - Dirija-se diretamente às pessoas e evite instruções passivas quando for possível usar uma frase ativa e clara. - Use termos coerentes e adequados ao público. Em textos para o público externo, prefira “pessoas em quem você confia” e “fragmentos”; em instruções dirigidas aos destinatários, termos de relação como “amigos” podem ser apropriados. - Evite pontos de exclamação, palavras de preenchimento, afirmações grandiosas, formulações mecânicas e entusiasmo forçado. - Use travessões com espaços dos dois lados, em vez de hífens duplos ou travessões sem espaços. - Mantenha as mensagens de estado concisas, mas humanas, e comunique o sucesso com serenidade em vez de deixá-lo em silêncio. Prefira uma linguagem visual suave, acolhedora e não corporativa, com contraste moderado. Centralize os valores da paleta, evite preto puro, vermelho vivo e azul corporativo, e mantenha qualquer exceção visual intencional isolada e documentada. ## Atualizar a documentação e escrever o histórico pelo que o usuário percebe Quando o comportamento mudar, atualize a documentação, as orientações para colaboradores e as instruções operacionais relevantes na mesma mudança. As notas de arquitetura devem explicar os limites dos ambientes de execução, os recursos gerados, as exceções de rede e os comandos necessários para reproduzir os resultados. - Mantenha as instruções de configuração e compilação sincronizadas com a implementação. - Atualize os dados de teste e as orientações de migração quando um formato estável mudar. - Escreva entradas do histórico de mudanças em torno do que mudou para a pessoa que usa o software. - Comece pelo resultado voltado ao público e inclua apenas o contexto de implementação necessário para compreendê-lo. - Omita refatorações internas e reorganizações de código, a menos que alterem o comportamento observável. Leia as entradas próximas antes de escrever uma nova para manter consistentes a voz e o nível de detalhe. ## Deixar o contribuidor revisar e enviar ele mesmo o que vai para fora Antes de qualquer ação que escreva em um rastreador externo de problemas ou serviço de hospedagem de código, leia a política de contribuições do projeto. Quando essa política exigir responsabilidade humana, pare antes de publicar e explique que a pessoa colaboradora é responsável por cada linha de código e de texto. - Mostre a diferença proposta, a mensagem de commit ou a descrição da contribuição para revisão humana. - Peça à pessoa colaboradora que edite o material com as próprias palavras, preencha as declarações com honestidade e realize pessoalmente o commit, o push e o envio. - Remova antes do envio os rodapés gerados, as linhas de coautoria, o conteúdo de preenchimento e a atribuição automatizada. - Não realize a gravação externa, a menos que a pessoa colaboradora insista explicitamente depois que o requisito de responsabilidade tiver sido explicado. - Se ela ainda assim insistir, mantenha a mensagem concisa e direta, não adicione atribuição automatizada e repita uma vez o requisito de revisão humana. A assistência para edição local e a inspeção somente leitura não ativam essas restrições de gravação externa. A automação de versões ainda deve executar compilações, testes, lint, verificações no navegador, empacotamento multiplataforma e somas de verificação, além de gerar artefatos representativos antes da publicação.