Adicione recursos a um app desktop em camadas e teste cada compilação

## Defina o que cabe ao núcleo, ao host desktop e à interface Defina as plataformas distribuídas, os clientes compatíveis, a topologia dos processos e os limites de confiança antes de alterar o código. - Mantenha as regras de negócio, a persistência, a execução e o comportamento do domínio em um núcleo autoritativo. - Atribua ao host desktop a responsabilidade pelo ciclo de vida, pelos recursos nativos, pela ponte segura e pelo empacotamento. - Atribua à interface voltada para a Web a apresentação, a navegação e a orquestração; não duplique as regras do núcleo no processo de renderização. - Encaminhe as chamadas da interface para o núcleo por uma única abstração de transporte autenticada, em vez de usar acessos diretos improvisados. - Trate clientes experimentais como superfícies de compatibilidade separadas, com estados explícitos de transporte, criptografia e lançamento. - Mantenha um mapa da arquitetura que identifique cada camada, o estado sob sua responsabilidade, suas interfaces públicas e as responsabilidades que lhe são proibidas. ## Classifique comandos por risco e limite as ferramentas à pasta do usuário Centralize a configuração e aplique uma única política de negação por padrão a todas as ferramentas que executam ações. - Leia valores do ambiente por meio de módulos de configuração tipados; o código dos recursos não deve acessar diretamente variáveis de ambiente do processo nem da fase de compilação. - Modele a autonomia como níveis explícitos combinados com limites do espaço de trabalho, raízes confiáveis e permissão de instalação. - Classifique os comandos como leitura, escrita, rede, instalação ou destrutivos; trate comandos não reconhecidos como operações de escrita. - Para cada classe, determine permitir, solicitar confirmação ou bloquear de acordo com o nível ativo. Sempre bloqueie locais do sistema e de credenciais. - Separe a raiz de ações do usuário do estado interno da aplicação. As ferramentas só podem atuar dentro da raiz de ações e nunca devem gravar diretamente no estado interno. - Mantenha as barreiras de aprovação ativadas por padrão para alterações interativas, encerre solicitações sem resposta após o prazo e faça o vencimento negar a ação. - Combine a validação de caminhos no nível da aplicação com uma área isolada do sistema operacional ou de contêiner; o isolamento é uma defesa em profundidade, não um substituto para as verificações de política. ## Dê a cada domínio seu próprio módulo no núcleo Dê a cada domínio um módulo próprio, com responsabilidade clara e arquivos pequenos e combináveis. ### Use uma estrutura de módulo canônica - Mantenha a fachada do módulo concentrada em exportações e livre de lógica de negócio. - Coloque tipos de domínio serializáveis, persistência, operações, esquemas de controladores, ferramentas de agentes, assinantes de eventos e testes em arquivos separados quando essas responsabilidades existirem. - Coloque as ferramentas que pertencem ao domínio junto ao próprio domínio e reserve a infraestrutura compartilhada de ferramentas para comportamentos realmente transversais. - Limite os módulos de transporte a autenticação, despacho, registro de eventos, observabilidade e questões de protocolo. Exponha os controladores por meio de um registro de pares de esquema e manipulador. Um novo comportamento deve acrescentar um controlador de domínio e registrá-lo em um único ponto de composição, em vez de multiplicar ramificações por nome de comando por todo o código de transporte. ## Mantenha as opções de ligar e desligar em tempo de execução separadas dos recursos de compilação Modele dois eixos independentes: - Um conjunto de serviços seleciona os serviços e transportes em segundo plano que estarão em execução. - Um conjunto de domínios seleciona as famílias de domínio disponíveis em tempo de execução. - Recursos de compilação removem código e dependências de variantes do produto. A filtragem em tempo de execução deve remover da superfície ativa os controladores, as ferramentas, os armazenamentos e os assinantes de um domínio desativado. As barreiras de compilação devem funcionar em conjunto com esse comportamento sem alterar a compilação padrão. Mantenha o ponto de registro como fonte autoritativa para impedir divergências entre esquemas, despacho, ferramentas e serviços de inicialização. ## Escolha como desligar recursos opcionais pelas dependências reais Escolha a menor barreira que preserve o comportamento sempre ativo. 1. Use uma barreira de folha quando todas as referências externas forem pontos de registro; as superfícies de recursos desativados devem estar ausentes, não ser registradas como substitutos que falham. 2. Use uma fachada com substitutos de comportamento somente quando chamadores sempre compilados exigirem símbolos que possam ser chamados. 3. Separe os tipos compartilhados sem dependências em módulos sempre compilados e substitua apenas o comportamento. Nunca duplique definições de tipos entre compilações ativadas e desativadas. 4. Divida um diretório quando alguns utilitários atenderem a domínios sempre ativos; proteja as arestas reais de dependência, não os nomes das pastas. 5. Preserve funções auxiliares essenciais mesmo quando estiverem sob um domínio opcional. Não substitua uma implementação necessária por um substituto que aparente sucesso. Quando um comando continuar visível apesar de seu recurso ter sido excluído da compilação, retorne um erro explícito de compilação com recurso desativado, em vez de um erro enganoso de comando desconhecido. Para dados inertes na compilação que ainda nomeiam componentes desativados, faça a resolução tolerar identificadores ausentes e teste esse contrato. Nunca alegue que uma barreira de recurso remove dependências apenas porque a compilação foi bem-sucedida. Comprove cada remoção alegada com uma consulta inversa à árvore de dependências na configuração desativada. ## Teste compilações com recursos opcionais ligados e desligados Trate os testes como parte da arquitetura e abranja comportamento, integração e empacotamento. - Coloque testes unitários focados junto ao código correspondente e prefira o comportamento observável aos detalhes de implementação. - Use um serviço simulado compartilhado em testes de integração determinísticos; proíba acesso real à rede e pausas dependentes de tempo nas suítes unitárias. - Defina cenários de ponta a ponta antes da implementação, incluindo fluxos bem-sucedidos, falhas, barreiras de autorização e recuperação. - Teste recursos opcionais nos dois sentidos: comprove o registro quando ativados e a ausência quando desativados. - Execute explicitamente a suíte de testes da compilação desativada. Uma etapa rápida que apenas compila não inclui o código de teste e não pode comprovar que os testes protegidos continuam válidos. - Imponha um limite de cobertura para linhas alteradas e recorra à suíte completa quando a configuração compartilhada ou contratos fundamentais mudarem. - Compile artefatos dispendiosos de plataforma uma vez e distribua os testes a partir desse artefato quando o sistema de compilação permitir. ## Adicione registros de diagnóstico que não guardem segredos nem dados pessoais Fluxos novos e alterados exigem diagnósticos na entrada, na saída, nas ramificações, nas chamadas externas, nas novas tentativas, nos limites de tempo, nas transições de estado e nos erros. - Use prefixos de domínio estáveis e fáceis de localizar, além de campos de correlação como identificadores de solicitação e nomes de métodos. - Mantenha os registros normais concisos, mas torne os níveis de depuração e rastreamento suficientes para investigações direcionadas. - Nunca registre em análises segredos, credenciais brutas, dados pessoais completos, conteúdo criado pelo usuário, identificadores de entidades, nomes de arquivos nem mensagens de erro brutas. - Encaminhe as análises por uma única API de recursos que respeite o consentimento e use nomes de eventos estáveis e sem conteúdo. - Considere a ausência de diagnósticos uma implementação incompleta quando a alteração introduzir um novo caminho de execução. ## Traduza todos os textos da interface e não edite à mão os documentos gerados Use estado, transporte e localização centralizados, em vez de atalhos locais. - Prefira a camada designada de estado da aplicação ao armazenamento disperso no navegador. - Use o cliente compartilhado do núcleo para todas as chamadas ao núcleo e mantenha transportes paralelos alinhados em seu comportamento. - Proteja APIs exclusivas do ambiente nativo por meio do detector de execução e do limite de erros compatíveis. - Encaminhe toda cadeia visível pela localização, acrescente traduções reais para cada localidade compatível e preserve exatamente os marcadores de interpolação. - Execute verificações de sintaxe da localização, vazamento de inglês e cobertura antes da conclusão. - Nunca edite manualmente blocos de documentação gerados. Atualize o marcador de origem, gere-os novamente e faça as verificações de divergência rejeitarem saídas desatualizadas. - Evite acrescentar injeção de scripts a exibições incorporadas de terceiros; implemente novos comportamentos por meio de manipuladores nativos, ferramentas de protocolo ou pontos de IPC controlados. ## Crie cada recurso do núcleo até a interface, testando cada camada antes de seguir Siga um fluxo vertical fixo: 1. Especifique o comportamento com base nos contratos de domínio existentes, nas convenções de nomenclatura, na política de segurança e nos cenários de ponta a ponta. 2. Implemente a lógica de domínio autoritativa com testes unitários. 3. Comprove o limite do controlador ou de RPC com um teste de integração. 4. Disponibilize o comportamento na interface por meio do cliente compartilhado, mantendo as regras no núcleo. 5. Acrescente testes unitários da interface e cobertura de ponta a ponta nas plataformas. 6. Atualize os dados descritivos dos recursos voltados ao usuário e a documentação da arquitetura quando um recurso for adicionado, removido ou renomeado. Não avance para a camada seguinte enquanto a camada atual não tiver sido testada. Mantenha os módulos pequenos e com finalidade única, e atualize a documentação junto com o comportamento que ela rege. ## Não pule verificações obrigatórias e mostre os resultados antes de concluir Faça as alterações em uma ramificação dedicada, direcione-as à ramificação de integração definida pelo repositório e mantenha os lançamentos de produção vinculados à fonte de lançamento declarada. - Use, a partir da raiz do repositório, o gerenciador de pacotes canônico, a cadeia de ferramentas fixada, o formatador, o analisador estático, o verificador de tipos e os executores de testes. - Mantenha sincronizadas as configurações equivalentes dos perfis de compilação entre componentes nativos compilados separadamente. - Nunca contorne ganchos ou verificações obrigatórios para ocultar falhas. Se um gancho gerar arquivos, revise e inclua os resultados e, em seguida, execute-o novamente. - Corrija as falhas causadas pela alteração; documente impedimentos anteriores e não relacionados, em vez de enfraquecer silenciosamente as proteções. - Revise a diferença final para verificar a consistência entre implementação, testes, esquemas, artefatos gerados, localização e documentação. - Não declare a conclusão sem resultados diretos das verificações pertinentes a cada camada alterada e a cada configuração de compilação compatível.