Projets personnels
Ces règles sont obligatoires dans les projets qui adoptent explicitement personal@tj-agents. L'adoption enregistre la portée personnelle du projet ; un répertoire personnel, un nom d'auteur ou une association avec un employeur ne l'établit jamais. Les projets d'un employeur restent en dehors de ce profil, sauf si Tommy change explicitement cette portée.
Conservez une seule solution actuelle supportée. Lors du remplacement d'un comportement, supprimez les noms, alias, implémentations de repli, adaptateurs, formats de configuration et branches de compatibilité obsolètes. Coordonnez et migrez tous les appelants connus, les déclarations de projet, les registrations installées, les artefacts générés et les points d'entrée runtime actifs dans la même transition. Ne conservez pas de comportement obsolète pour des utilisateurs externes hypothétiques ; coordonnez les mises à niveau avec les développeurs collaborateurs réels.
Vérifiez les points d'entrée que les gens utilisent réellement sur chaque plateforme supportée, y compris les chemins de lancement Windows et Linux lorsqu'ils sont supportés. Les modifications de code source, une génération réussie, des tests unitaires passants et des commandes de version ne prouvent pas à eux seuls qu'une migration est terminée. Vérifiez les bindings installés et le comportement runtime frais. Enregistrez tout point d'entrée non vérifié comme incomplet, avec son résolveur et sa condition d'acceptation observable.
Par exemple, remplacer old-launch par launch signifie migrer la commande shell enregistrée, la configuration du projet et les appelants réels, supprimer l'ancienne entrée, puis invoquer launch depuis une session fraîche sur chaque système d'exploitation supporté. Exécuter launch --version seul laisse la transition non vérifiée.
Remplacer old-launch par launch :
1. Migrer la commande shell enregistrée, la configuration et les appelants réels.
2. Supprimer l'ancienne entrée et régénérer les paramètres installés.
3. Invoquer launch depuis une session Windows/Linux fraîche supportée et vérifier son comportement réel.
Résultat : launch --version seul laisse cette migration incomplète.
N'ajoutez pas indépendamment une exception de rétrocompatibilité. Présentez une exigence utilisateur contraire explicite comme une décision de politique délibérée, identifiez le comportement supporté affecté et réconciliez la portée de ce profil avant de l'implémenter. Ne cachez jamais une exception dans un repli ou un adaptateur.
Résolvez le problème démontré avec l'implémentation la plus petite adaptée. N'ajoutez des abstractions, dépendances, commutateurs de configuration, chemins en double ou mécanismes de traitement que pour un besoin concret actuel. Préférez les capacités que le projet sélectionne déjà. Vérifiez le comportement et les chemins d'échec significatifs à la mesure du changement ; n'ajoutez pas de tests qui ne font que répéter l'implémentation ou une liste de contrôle sans bénéfice concret.
Cette politique est rédigée une fois ici. L'adoption personnelle génère son bloc natif d'instruction marquée à partir de ce corps et vérifie sa conformité. Un plugin sélectionné ou un seul niveau always ne constitue pas une preuve de chargement.