Projetos pessoais
Estas regras são obrigatórias em projetos que adotam explicitamente personal@tj-agents. A adoção registra o escopo pessoal do projeto; um diretório home, nome de autor ou associação com empregador nunca o estabelece. Projetos do empregador permanecem fora deste perfil, a menos que Tommy altere explicitamente esse escopo.
Mantenha uma única solução atual suportada. Ao substituir um comportamento, remova os nomes supersedidos, aliases, implementações de fallback, adaptadores, formatos de configuração e branches de compatibilidade. Coordene e migre todos os chamadores conhecidos, declarações de projeto, registros instalados, artefatos gerados e pontos de entrada de tempo de execução ativos na mesma migração. Não retenha comportamento obsoleto para usuários externos hipotéticos; coordene as atualizações com os desenvolvedores colaboradores reais.
Verifique os pontos de entrada que as pessoas realmente usam em cada plataforma suportada, incluindo caminhos de inicialização do Windows e Linux quando suportados. Edições de código-fonte, geração bem-sucedida, testes unitários aprovados e comandos de versão sozinhos não provam que uma migração está completa. Verifique bindings instalados e comportamento de tempo de execução recente. Registre qualquer ponto de entrada não verificado como incompleto, com seu resolvedor e condição de aceitação observável.
Por exemplo, substituir old-launch por launch significa migrar o comando de shell registrado, a configuração do projeto e os chamadores reais, excluir o ponto de entrada antigo e, em seguida, invocar launch de uma sessão nova em cada SO suportado. Executar launch --version sozinho deixa a migração não verificada.
Substituir old-launch por launch:
1. Migrar o comando de shell registrado, configuração e chamadores reais.
2. Excluir o ponto de entrada antigo e regenerar as configurações instaladas.
3. Invocar launch de uma sessão nova suportada do Windows/Linux e verificar seu comportamento real.
Resultado: launch --version sozinho deixa essa migração incompleta.
Não adicione uma exceção de retrocompatibilidade de forma independente. Explicite um requisito contrário do usuário como uma decisão de política deliberada, identifique o comportamento suportado afetado e reconcilie o escopo deste perfil antes de implementá-lo. Nunca esconda uma exceção em um fallback ou adaptador.
Resolva o problema demonstrado com a menor implementação adequada. Adicione abstrações, dependências, chaves de configuração, caminhos duplicados ou mecanismos de processo apenas para uma necessidade concreta atual. Prefira as capacidades que o projeto já seleciona. Verifique o comportamento e os caminhos de falha significativos na proporção da mudança; não adicione testes que apenas repitam a implementação ou uma lista de verificação sem benefício concreto.
Esta política é criada uma vez aqui. A adoção pessoal gera seu bloco de instrução nativo marcado a partir deste corpo e verifica desvios. Um plugin selecionado ou uma camada always sozinho não é prova de carregamento.