Permitir Cambios Rupturistas

¿Qué hace Permitir Cambios Rupturistas?

Trata la compatibilidad con el comportamiento histórico propiedad del proyecto como opcional para el resto de la conversación actual. Prefiere la arquitectura sólida más simple para los requisitos actuales; no rompas el comportamiento solo por novedad.

Activar y Mantener la Política

1. Actívala solo después de una invocación explícita de $allow-breaking-change.
2. Para una invocación simple, confirma la activación y su límite de protección de datos en una oración concisa, luego espera una tarea. Para una invocación con una tarea, activa primero y luego maneja la tarea.
3. Aplica la política en todos los proyectos y tareas, incluyendo planificación, diseño, revisión, diagnóstico e implementación, hasta que la conversación termine o el usuario la desactive explícitamente.
4. Trata una instrucción clara a nivel de tarea como mantén la compatibilidad para esta tarea como una anulación temporal. Trata una instrucción clara como desactivar allow-breaking-change como una revocación para el resto de la conversación.
5. Menciona la política activa solo cuando la compatibilidad afecte una decisión o resultado. No repitas un recordatorio de estado en turnos no relacionados.
6. Continúa obedeciendo instrucciones de mayor prioridad, requisitos del repositorio y restricciones explícitas de la tarea actual.

Tomar Decisiones Sin Compatibilidad Histórica

• Excluye la compatibilidad hacia adelante y hacia atrás con APIs heredadas propiedad del proyecto, CLIs, configuración, protocolos y formatos de archivo de los criterios de decisión.
• No agregues adaptadores, períodos de deprecación, implementaciones paralelas, puentes de versiones ni análisis heredados únicamente para preservar consumidores históricos.
• Actualiza todos los llamadores, pruebas, documentación, ejemplos y artefactos generados dentro del alcance al nuevo contrato.
• Clasifica las pruebas antiguas por intención. Elimina o reescribe aserciones que existen solo por compatibilidad; conserva los requisitos de corrección, seguridad, integridad de datos, accesibilidad y comportamiento actual.
• Aún considera el esfuerzo de implementación, el riesgo de regresión, la dificultad de validación, el rendimiento y el riesgo operativo. El permiso para romper la compatibilidad no es permiso para expandir el alcance de la tarea o realizar acciones destructivas.
• Continúa respetando estándares externos, ABIs de plataforma, contratos activos de terceros y otros requisitos de interoperabilidad que sigan siendo parte de la tarea actual.

Juzgar la Arquitectura con KISS y Unixify

Para cambios materiales en los límites de responsabilidad, interfaces, representaciones de datos o capas del sistema, aplica primero la habilidad instalada $kiss para eliminar conceptos y mecanismos innecesarios, luego aplica $unixify para dar forma a las responsabilidades, representaciones e interfaces de composición restantes. Omite este flujo de trabajo adicional para cambios mecánicos locales.

Anula únicamente las barreras de preservación de compatibilidad en KISS y Unixify mientras esta política esté activa. Preserva sus otras barreras, especialmente corrección, seguridad, integridad de datos, claridad, límites justificados y comportamiento de fallo observable.

Proteger Datos y Operaciones

• Cuando los datos almacenados deban moverse a una representación incompatible, proporciona y verifica una migración unidireccional sin pérdidas. Solo da soporte a la nueva representación después de la migración.
• Si una migración sin pérdidas es imposible, detente e informa la información o semántica que se perdería. Obtén una decisión específica para la tarea antes de realizar una migración con pérdidas.
• Introduce un puente de compatibilidad temporal solo cuando un requisito actual de disponibilidad o despliegue continuo haga necesaria la operación con versiones mixtas. Dale al puente una condición de eliminación explícita y elimínalo después de la transición.

Comunicar Cambios Rupturistas

No solicites permiso simplemente porque el diseño seleccionado sea rupturista. Identifica brevemente los principales contratos rotos, los llamadores o datos afectados, la migración requerida y la verificación realizada en el plan, informe de revisión o informe de finalización.