Proyectos personales
Estas reglas son obligatorias en los proyectos que adopten explícitamente personal@tj-agents. La adopción registra el ámbito personal del proyecto; un directorio personal, el nombre del autor o la asociación con un empleador nunca lo establecen. Los proyectos de empleadores quedan fuera de este perfil a menos que Tommy cambie explícitamente ese ámbito.
Mantén una única solución compatible actual. Al reemplazar un comportamiento, elimina los nombres, alias, implementaciones de respaldo, adaptadores, formatos de configuración y ramas de compatibilidad que hayan quedado obsoletos. Coordina y migra todos los invocadores conocidos, declaraciones del proyecto, registros instalados, artefactos generados y puntos de entrada en tiempo de ejecución activos en el mismo corte. No conserves comportamiento obsoleto para usuarios externos hipotéticos; coordina las actualizaciones con los desarrolladores colaboradores reales.
Verifica los puntos de entrada que la gente usa realmente en cada plataforma compatible, incluyendo las rutas de inicio de Windows y Linux cuando sean compatibles. Las ediciones de código fuente, la generación exitosa, las pruebas unitarias que pasan y los comandos de versión por sí solos no demuestran que una migración esté completa. Comprueba los enlaces instalados y el comportamiento en tiempo de ejecución fresco. Registra cualquier punto de entrada no verificado como incompleto, con su resolvedor y condición de aceptación observable.
Por ejemplo, reemplazar old-launch por launch significa migrar el comando de shell registrado, la configuración del proyecto y los invocadores reales, eliminar la entrada antigua, y luego invocar launch desde una sesión nueva en cada sistema operativo compatible. Ejecutar launch --version por sí solo deja el corte sin verificar.
Reemplazar old-launch por launch:
1. Migrar el comando de shell registrado, la configuración y los invocadores reales.
2. Eliminar la entrada antigua y regenerar las configuraciones instaladas.
3. Invocar launch desde una sesión nueva compatible con Windows/Linux y comprobar su comportamiento real.
Resultado: launch --version por sí solo deja esta migración incompleta.
No añadas una excepción de retrocompatibilidad por tu cuenta. Presenta un requisito de usuario contrario explícito como una decisión política deliberada, identifica el comportamiento compatible afectado y reconcilia el alcance de este perfil antes de implementarlo. Nunca escondas una excepción en un respaldo o adaptador.
Resuelve el problema demostrado con la implementación más pequeña adecuada. Añade abstracciones, dependencias, interruptores de configuración, rutas duplicadas o mecanismos de proceso solo para una necesidad concreta actual. Prefiere las capacidades que el proyecto ya selecciona. Verifica el comportamiento y las rutas de fallo significativas en proporción al cambio; no añadas pruebas que solo repitan la implementación o una lista de verificación sin beneficio concreto.
Esta política se escribe una vez aquí. La adopción personal genera su bloque de instrucciones nativo marcado a partir de este cuerpo y lo verifica para detectar desviaciones. Un plugin seleccionado o un nivel always por sí solo no es prueba de carga.